Salesforce.com Apex Unit Tests: Use Your Non-Test Best Practices

Unit Tests Are Code Too

Unit tests are the crazy relative that the rest of the family pretends doesn’t exist. Nobody likes to invite them to family functions, and when they are invited, they’re never the guest of honor. Nobody pays any attention to them, and when people do talk about them, it’s usually with some measure of guilt for having neglected them for so long.

I don’t know about your crazy relatives, but your unit tests deserve better. Once you get to know them, your unit tests (and, quite possibly, your crazy relatives) can become your best friends. They deserve to be treated with the same care and best practices that you apply to your regular Apex code.

Let’s look at a few specifics.

Consolidate frequently used code patterns into utilities methods

When you review your regular Apex code, you may find frequently used code patterns. For example, you may find that several of your triggers repeat the same lines of code to determine whether the current User’s Profile and Role entitle them to perform some action. A good programmer will consolidate that code into a utility method, rather than repeating it in every trigger. When it’s consolidated, if changes need to be made to the logic, you can make those changes in a single place, rather than trying to find every place that contains that logic.

The same practice should be followed for unit tests. Unit tests have to create the data they test with, and if you’re writing unit tests for your Account, Contact, and Opportunity triggers, each test probably repeats the same lines of code to create a test Account. Why repeat that code in every unit test? Instead, define a public class with the @isTest annotation, and define a static CreateAccount() method in it. Then call that method from each of your unit tests. Why?

• If someone adds a new required field to the Account object, you don’t have to modify all of your unit tests to define a value for it – instead, you only have to modify your CreateAccount() method.
• Your unit test code is more streamlined, and can focus on the code you’re testing, and not on the creation of the test data.

Comment, comment, comment

You comment your regular Apex code, don’t you? So why don’t you comment your test code? Your Apex code should contain comments that explain what you’re testing and why you expect certain results.  It only takes a few seconds to add comments while you’re writing your unit tests. At some point in the future, if your unit test starts to fail, someone is going to have to read your test code to find out what’s wrong. If your test code contains comments, that process will go a lot quicker!

It’s Not Over ‘Til The Fat Lady Sings

And you guessed it, unit tests are the fat lady.

If your boss asked you if you’ve finished writing that trigger yet, would you say “yes” if the answer was really “no?” (If you would, that’s a subject for another article!) Well, your job isn’t done until you’ve finished both the trigger and its unit tests. After all, if you haven’t written the unit tests, how can you be sure your trigger actually works? And if you haven’t written the unit tests, how will you be able to deploy that trigger?

At OpFocus, our estimates and schedules always include unit tests. A task isn’t done until the code is fully written and tested, and you can’t fully test until you’ve written and run the unit tests. Only then can the fat lady sing.

Are unit tests the fat lady, or your family’s crazy relative? Or does some other metaphor apply? Tell us what you think.

Photo Credit: Romano Groenewoud