Common Mistake: Focusing on lines covered and not
Let’s look at these examples.
Example 1: 100% Lines of Code Coverage
function divide(a,b){
return a / b;
}// Test Case: Success divide(1,1); // Expect 1
So at this point we have 100% code coverage in terms of lines of code. Each line gets executed. However, we aren’t adequately accounting for different cases. What if someone divides by zero?
Example 2: Different Test Cases
function divide(a,b){
return a / b;
}// Test Case: Success divide(1,1); // Expect 1
// Test Case: Infinity divide(1,0); // Expect Infinity
This is just a rudimentary example, but the point is lines of code coverage alone is not a good measure of test coverage.
In fact, when you use a measure as a goal, it ceases to be a good measure. So while Salesforce has the best intentions for requiring code coverage on all Apex code, my best guess is that 75% is just an arbitrary number.
To avoid this mistake, and start to really understand how to write good unit tests, I suggest reading the following:
Common Mistake: Apex Unit Test Coverage Only.
There are two problems with a situation where there is only unit test coverage on Apex code:
- Unit Tests aren’t the only type of test.
- Apex probably isn’t the only code on your org.
To avoid this particular mistake, you need to develop a good testing mindset, which takes practice. A good first step is to learn about the different types of software testing: Testing Types, Techniques, Tactics.
Chances are, if you have customizations, you probably have JavaScript on your org as well… is that code tested?
Common Mistake: Too Much Mocking.
Alright, I’m going to be completely honest here. Mocking is an easy way to squeeze out some extra lines of code coverage for Apex. So maybe that’s the reason you have a ton of mocks in your test code. But the reality is, you shouldn’t be doing much mocking if you’re writing quality code. Mocking itself is actually a code smell.
Common Mistake: Code First, Test Later.
“If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.” — Albert Einstein
Test early and often. If you are waiting until you’re ready to deploy to write tests, you’re waiting too long.
The most hardcore of Test Driven Developers will say write tests first, and code until your tests pass. But the reality is, not many of us are blessed with ironclad requirements. It’s an iterative process and sometimes you can’t define a problem until you start to solve it. So if you start coding too early, or writing tests too early, you will likely need to change your code and your tests.
So to avoid this problem, use a pen and paper. Seriously. Try to solve the problem without coding. Then do test driven development, but don’t skip the time you need to think about problems. typing != programming
Need Help With Testing Software on the Salesforce Platform?
Our team at Eigen X has worked with a variety of testing tools related to the Salesforce Platform. If you’re concerned or have questions about the test coverage and reliability of your code drop us a line: jlombard@eigenx.com.