Apex Testing Best Practices

I’ve been talking about Apex code test a lot lately and wanted to post a brief note about some of the most important things to consider when writing Apex tests. This is not a complete list by all means, but I feel these points sometimes get lost in the longer posts. Some excellent reading: An Introduction to Apex Code Test Methods and How to Write Good Unit Tests.

Create Your Own Test Data

Never rely on existing data for your tests. Version 24.0 and above encourage this even more as they don’t allow access to existing data by default. You should create all your test data and use it during the testing. If you have a lot of test data, set up a factory to build your test data so you don’t to constantly repeat yourself when creating Accounts. Take a look at Smart Factory for one way to do this.

Also, you don’t have to worry about cleaning up your test data since it never actually commits it to the database. The tests are run but your users are non the wiser. A couple of side effects: your recently used list is usually empty after you’ve run tests that create a lot of records and auto-numbers get incremented, so there can be gaps in your numbering sequence on object like cases.

Test Small Parts

Each of your tests should only test a small part of the code. If you have a bunch of helper classes, each of those helper classes should all have their own test classes rather than relying on testing the helper classes by using other classes that may call the helpers.

Test All Scenarios

I see too many people shooting for 75% code coverage without actually thinking about the various scenarios that could be encountered once the code gets into production. For example, if you have a trigger on accounts, actually test it for bulk by creating 200 accounts and inserting them at one time to the database. Also test various permutations of data. If you have code that does something with accounts and contacts, have you considered a test case where there is a contact without an account, a person account or maybe an account without contacts? Put all these possible scenarios into your test class.

Always Assert

Never assume that because the code ran with no exceptions thrown and you have more than 75% code coverage that your code did what you actually wanted. Remember that all tests are run in your org every time you deploy new code to make sure the new code plays well with everything else in the org. Also, Salesforce runs all tests in all orgs several times before each release to make sure they aren’t breaking existing code out there. The only way for them to really know is if your code has assertions and those fail.

Conclusion

Remember, testing is required for a reason. It makes you a better coder because you have to think about all the scenarios your code might encounter. Don’t think of it as an onerous process that you hate at the end. Write your tests as you go or even before you code your classes.

What are some best practices you like to see when writing tests?

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s