Salesforce Apex Testing Essentials
-
Welcome to Salesforce Ben Courses1 Topic
-
Introduction5 Topics
-
Basics9 Topics
-
Testing Triggers10 Topics
-
Test Data Creation10 Topics
-
Overview
-
DON’T Use A Single Test Data Class
-
SObject Test Data Framework
-
Create SObjectTestData Class
-
Add Default Account Source to AccountTestData
-
Implementing an SObject Test Data Class
-
Implement OpportunityTestData Class
-
Add Create and Insert Object Functions
-
Full OpportunityTestData Class
-
Test Data Creation Exercises
-
Overview
-
Testing Asynchronous Apex7 Topics
-
Best Practices7 Topics
-
Wrap Up1 Topic
Considerations
Now, let’s talk about some considerations regarding Apex Test code.
Takes 1-3X as Long as Creating Production Code
Anecdotally, writing proper Apex Test code takes at least 1-3 times as long to create as production test code. Put differently, if it takes an hour to write production test code, it’ll take 1-3 hours to write proper, comprehensive Apex Test code. It takes longer because there are typically numerous test cases with varying test inputs.
This is based on my experience and provides a guideline only.
100% Test Code Coverage is an Illusion
100% test code coverage is often touted to mean that one’s software is completely tested without any bugs. That is an illusion because you can have Apex Test code that simply runs the production code but doesn’t check to see that it works properly. I’ve seen this done repeatedly by other developers. Since Salesforce only measures how much of the production code is executed by the Apex Test code, it is fairly easy to work around the Salesforce test code coverage requirements.
Another reason is that you often test a small subset of all the possible inputs using your test code. For example, if you have an add function like this that adds two Integers together and returns their sum:
public Integer add (Integer a, Integer b) {
return a + b;
}
you could have some test code to ensure that 1 + 1 is 2 and it’ll be 100% covered. However, if one gives the function other input, the function won’t work properly. For example:
Integer sum = add(2147483647, 4);
will cause an Integer overflow and the add function will return the wrong number because an Integer has a maximum value of 2,147,483,647. The number of possible inputs can be so numerous that it’s practically impossible to test them all.