If you take nothing else away from this chapter, let it be this—tests without assertions are not tests, but liabilities. Without the assert calls, you cannot check the outcome of your executed code block to see if it functioned properly. That's why I refer to test methods without assert calls as liabilities. Inevitably, when the code fails for whatever reason, you're accountable for the consequences. At 3am. On a Saturday. It's even worse, if your code is mission critical and fails at the quarter's end! Practice safe testing, use asserts.
The Salesforce1 platform provides us with three basic assertion methods. The first method, System.Assert(expression), evaluates the expression within for a Boolean true or false. Thus, you can use it like this:
System.assert(1 = 1) System.assert(BooleanVariable) System.assert(p != np)
The other two built-in assertion methods are really shorthand, convenience methods built on top of System.assert. They are System.assertEquals(expected, actual) and System.assertNotEquals(expected, actual). These often read easier than a simple System.assert() call. Here are a few examples:
System.assertEquals(1,1) System.assertNotEquals(false, BooleanVariable) System.assertNotEquals(P, NP)
It's important to remember that each of these built-in assert methods can accept an optional final parameter that I call the friendly message. You should always use the friendly message option, as it will help you debug which assertions and which tests are failing. You will only ever see the friendly message when a test fails. To use the friendly message, simply add a string parameter to the method call; for instance:
System.assertNotEquals(P, NP, 'Oh noes! P = np means all cryptography is flawed!')
Often, it can be useful to create your own assertion methods. Complex comparisons of objects and situations where multiple assertions must all pass are excellent candidates for custom assertion methods. Creating an assertion method is as simple as creating any other method, but to be used as an assertion, the method must either return true or throw an exception. It's a good idea to maintain the friendly message concept, so it pays to accept a friendly message parameter. If your assertion method needs to throw an exception, use the friendly message as the exception's message. If, for instance, we want to build an assertion method that proves that two contacts are from the same household, we might write it like this:
@isTest
public class customAssertions {
public class customAssertionException extends Exception {}
public static Boolean ContactsAreFromSameHousehold(Contact firstContact, Contact secondContact, String friendlyMessage){
System.assertEquals(firstContact.mailingAddress, secondContact.mailingAddress, 'MailingAddress: ' + friendlyMessage);
System.assertEquals(firstContact.homePhone, secondContact.homePhone, 'homePhone: ' + friendlyMessage);
System.assertEquals(firstContact.lovesCrankCalls, secondContact.lovesCrankCalls, 'lovesCrankCalls: ' + friendlyMessage);
if(firstContact.fullName == secondContact.fullName){
throw new customAssertionException('Full Names are identical: ' + friendlyMessage)
}
return true;
}
}Here, we're both compiling standard assertions that now must all pass as well as a custom comparison. If any of the three standard assertions called here fail, or if the custom full name comparison fails, an exception is raised and the assertion fails.
We talked about what asserts are and how to use them, so let's take a second to consider when to use them. All tests should have at least one assertion after the call to stopTest(). Better tests will have multiple assertions identifying, for instance, that the object returned not only had the proper record type, but that it was properly modified by the executed code. Best yet, are the test methods that include two assertion blocks in addition to the standard after stopTest() assertions, the best tests will include a block asserting that your test data was created properly. This is especially important as you try to identify falsely failing tests. If the code works when manually executed via anonymous Apex or the UI, but fails in the tests, you may have a problem with your test data. Asserting that X number of contacts were created helps you identify the problem.