Throughout the software development lifecycle, it’s valuable to fail fast. When something isn’t right with your product, you want to know ASAP.
There are a number of ways to fail: failure in automated tests and reporting, your source code failing to compile, QA finding edge cases you neglected, and many more. The sooner you fail, the sooner you can recover and learn from it. Today, I’ll be covering one method to help you fail faster as a developer.
Assertions! But you’re already using those right? You’re using them liberally throughout your test methods to assert that your test code produces the desired output. I’m here to tell you that assertions are also useful outside of test methods. When used in test methods, an assertion will cause an unrecoverable error that will make your test method report failure. As crazy as it may sound, an unrecoverable error in your regular code can be desirable.
Why not Exceptions?
Exceptions perform a similar function, but assertions have their place too. Agile speaker, trainer and author James Shore says, “Assertions are the key to failing fast.” Assertions are not recoverable. When we use an assertion, we want to fail fast here and we want to fail hard. Assertions are meant to catch conditions that could be categorized as impossible. Assertion failures are caused by developers, and are fixed by developers. For example, an assertion could catch a developer calling a function with the wrong arguments or with arguments that are not within the acceptable range. User input should have no effect on whether or not an assertion failure occurs. An assertion is a tool for development, not for the normal day-to-day function of an application.
Test Coverage
If you already have quality test coverage for your code, why would you want assertions in the methods themselves? I’m going to answer that with my favorite example involving the Id data type. Take this function signature which inserts an AccountContactRole as an example:
private static void createAccountContactRole(Id accountId, Id contactId, String roleName)
What happens if you pass in a Contact Id as the first argument, and an Account Id as the second argument? The call to the function will succeed because the function doesn’t care what underlying SObject is behind each Id.
Further along in the function when you attempt to insert the AccountContactRole, you’ll get a message like this: “System.DmlException: Insert failed. First exception on row 0; first error: FIELD_INTEGRITY_EXCEPTION, Account ID: id value of incorrect type”. After a little bit of head scratching, you’ll eventually figure out that you’ve flip-flopped your arguments when calling that function from somewhere else in your code. With a pair of assertions, we can catch the error earlier in the flow of execution, and expose more information to speed up the debugging process. That’s failing faster!
System.assertEquals(Account.SObjectType, accountId.getSObjectType(), 'Invalid ID Type passed to createAccountContactRole');
System.assertEquals(Contact.SObjectType, contactId.getSObjectType(), 'Invalid ID Type passed to createAccountContactRole');
This’ll produce a more helpful error, “System.AssertException: Assertion Failed: Invalid ID Type passed to createAccountContactRole: Expected: Account, Actual: Contact”. From that error message, it’s clearer that the arguments have been flip flopped.
I want to reinforce that this is a developer error. Passing arguments in the correct order is not the user’s responsibility, it’s the developer’s responsibility. Asserts are also a form of documentation. If you’ve got a method that absolutely must receive a string of length 3 or greater, consider asserting it. That way, when you or another developer attempts to use the method with a string that is too small, they receive immediate feedback. Even though their automated tests will fail, they’ll know exactly what is wrong when the assert is the part that triggers the failure.
Closing
Don’t assert things that are expensive to calculate. Assertions in private methods are generally ok, but assertions in public methods should be thoughtfully examined before implementing. If you use assertions sparingly and carefully, you’ll fail faster — and fail better.
Need a helping hand with your AppExchange app development? We’ll assert that we’re a great partner to organizations looking to succeed on the AppExchange — contact us for a free consultation!
