Skip to main content
replaced http://salesforce.stackexchange.com/ with https://salesforce.stackexchange.com/
Source Link

So your test is actually failing, but you did not write it correctly. Right now, if you do not get any DmlException, you have no assertion. At the very least, you would need to assert that you don't execute the rest of the try block:

try
{
    delete someRecords;
    system.assert(false, 'The operation should fail');
}

However, I really loathe conditional assertions of any kind. Write your test methods so that every assertion gets hit every time the test is run.

DmlException expectedException;
try
{
    delete someRecords;
}
catch (DmlException d)
{
    expectedException = d;
}

system.assertNotEquals(null, expectedException,
    'There should be a validation error');
system.assertEquals(someRecords.size(), [SELECT count() FROM MyObject__c],
    'The records should not be deleted');

Note that I assert on the records being in the database. This information is much more useful than the content of the exception message. Don't assert on that. It's an implementation detail and doesn't really matter.

So all of the above just tells you how to write a test that fails properly. Once you get this far, you will see that the records you are trying to delete do, in fact, get deleted. So now you need to set up your records so they will fulfill the validation criteria. The locking is easy now that you can just call Approval.lock(someRecords). But you need to create some ContentDocumentLink records and associate them to the ContentDocument records you want to delete.

Note that you have not properly bulkified your trigger. If you try to delete more than 100 records, you will hit a LimitException, because you have a query in a loop. Read up on General trigger bulkification - best practicesGeneral trigger bulkification - best practices

So your test is actually failing, but you did not write it correctly. Right now, if you do not get any DmlException, you have no assertion. At the very least, you would need to assert that you don't execute the rest of the try block:

try
{
    delete someRecords;
    system.assert(false, 'The operation should fail');
}

However, I really loathe conditional assertions of any kind. Write your test methods so that every assertion gets hit every time the test is run.

DmlException expectedException;
try
{
    delete someRecords;
}
catch (DmlException d)
{
    expectedException = d;
}

system.assertNotEquals(null, expectedException,
    'There should be a validation error');
system.assertEquals(someRecords.size(), [SELECT count() FROM MyObject__c],
    'The records should not be deleted');

Note that I assert on the records being in the database. This information is much more useful than the content of the exception message. Don't assert on that. It's an implementation detail and doesn't really matter.

So all of the above just tells you how to write a test that fails properly. Once you get this far, you will see that the records you are trying to delete do, in fact, get deleted. So now you need to set up your records so they will fulfill the validation criteria. The locking is easy now that you can just call Approval.lock(someRecords). But you need to create some ContentDocumentLink records and associate them to the ContentDocument records you want to delete.

Note that you have not properly bulkified your trigger. If you try to delete more than 100 records, you will hit a LimitException, because you have a query in a loop. Read up on General trigger bulkification - best practices

So your test is actually failing, but you did not write it correctly. Right now, if you do not get any DmlException, you have no assertion. At the very least, you would need to assert that you don't execute the rest of the try block:

try
{
    delete someRecords;
    system.assert(false, 'The operation should fail');
}

However, I really loathe conditional assertions of any kind. Write your test methods so that every assertion gets hit every time the test is run.

DmlException expectedException;
try
{
    delete someRecords;
}
catch (DmlException d)
{
    expectedException = d;
}

system.assertNotEquals(null, expectedException,
    'There should be a validation error');
system.assertEquals(someRecords.size(), [SELECT count() FROM MyObject__c],
    'The records should not be deleted');

Note that I assert on the records being in the database. This information is much more useful than the content of the exception message. Don't assert on that. It's an implementation detail and doesn't really matter.

So all of the above just tells you how to write a test that fails properly. Once you get this far, you will see that the records you are trying to delete do, in fact, get deleted. So now you need to set up your records so they will fulfill the validation criteria. The locking is easy now that you can just call Approval.lock(someRecords). But you need to create some ContentDocumentLink records and associate them to the ContentDocument records you want to delete.

Note that you have not properly bulkified your trigger. If you try to delete more than 100 records, you will hit a LimitException, because you have a query in a loop. Read up on General trigger bulkification - best practices

Source Link
Adrian Larson
  • 151.4k
  • 38
  • 247
  • 431

So your test is actually failing, but you did not write it correctly. Right now, if you do not get any DmlException, you have no assertion. At the very least, you would need to assert that you don't execute the rest of the try block:

try
{
    delete someRecords;
    system.assert(false, 'The operation should fail');
}

However, I really loathe conditional assertions of any kind. Write your test methods so that every assertion gets hit every time the test is run.

DmlException expectedException;
try
{
    delete someRecords;
}
catch (DmlException d)
{
    expectedException = d;
}

system.assertNotEquals(null, expectedException,
    'There should be a validation error');
system.assertEquals(someRecords.size(), [SELECT count() FROM MyObject__c],
    'The records should not be deleted');

Note that I assert on the records being in the database. This information is much more useful than the content of the exception message. Don't assert on that. It's an implementation detail and doesn't really matter.

So all of the above just tells you how to write a test that fails properly. Once you get this far, you will see that the records you are trying to delete do, in fact, get deleted. So now you need to set up your records so they will fulfill the validation criteria. The locking is easy now that you can just call Approval.lock(someRecords). But you need to create some ContentDocumentLink records and associate them to the ContentDocument records you want to delete.

Note that you have not properly bulkified your trigger. If you try to delete more than 100 records, you will hit a LimitException, because you have a query in a loop. Read up on General trigger bulkification - best practices