Developers who write Salesforce Apex logic understand the importance of Salesforce Test Coverage. Without Test Coverage, deploying to production is not possible. The average Salesforce Test Coverage across all classes needs to be at least 75%. In fact some development teams are so focused on testing they actually use a process called Test driven development. Using this process, Test Coverage is developed from the business specifications and then logic is written to pass those tests.
Salesforce Test Coverage is a deep topic with many areas and approaches to discuss. What I want to look at instead are some of the Annotations when thinking about Test Coverage.
Useful Annotations
The most common test related annotations are @isTest and @testSetup.
- @isTest – used at the Class or Method level to indicate it only contains code that supports Test Coverage. Classes defined with this annotation do not count against your organization limit for Apex code.
- @testSetup – used to indicate a method is specifically used to setup test data. When supplied, the @testSetup method is execute prior to any other methods in the test class. Each test method will have access to the original set of constructed test data regardless of how any other test method uses that data.
As a side note, the testMethod keyword is interchangeable with @isTest.
Exposing the Private Parts
When constructing Apex logic, it makes sense at times to define members such as methods, variables, and inner classes as private or protected. Doing so however can make achieving Test Coverage more challenging. Fortunately Salesforce has thought ahead and provided us with the @testVisible annotation. Using this annotation on private or protected members allows test class access but still preserves the defined visibility to non test classes.
Access to Data
Ideally, your Salesforce test classes should be responsible for creating their own data. However, sometimes you need access to existing data and using @isTest(SeeAllData=True) allows your test classes and test methods this access. Available as of API version 24.0, there are some caveats when using. “SeeAllData=True” can be used at the Class and Method level. When using “SeeAllData=True” at the Class level, all methods get access to existing data but using “SeeAllData=True” at just the Method level it only allows those Methods access to existing data. Lastly, using “SeeAllData=False” at the Method level will not override “SeeAllData=True” being used at the Class level. This really isn’t obvious but important none-the-less.
Writing Salesforce Test Coverage can be difficult at times. Hopefully, the annotations we’ve reviewed can make that journey easier. Often the person deploying or validating a deployment needs to fix existing, poorly written, failing test classes. If you would like help with Salesforce Test Coverage or failing test classes, please feel free to contact us at www.cirriussolutions.com/contact.
