Apex Trigger Test Coverage

Kris Sparks
3 min readFeb 16, 2018
Tangled pile of rope

Let’s untangle the subject of code coverage requirements for Apex Triggers on the Salesforce platform.

I recently inherited a Trigger that had been neglected for some time. The code was stringy, highly coupled and poorly tested. I added a few lines of code and tried to deploy it. It failed. The error:

0% code coverage. Each trigger must have at least 1% code coverage.

I ran the test in our production environment and in two sandboxes. It had 31 percent code coverage. I thought I would try find out why it would not deploy with 31 percent code coverage and render an error message indicating 1 percent is required.

I searched for the code coverage requirements for Apex triggers. Scouring the Internet I found two groups of people, one voting for 1% and another voting for 75%.

As it turns out, 75% code coverage is required on an individual Apex class and an average of 75% of code coverage is required across the organization. This includes classes and triggers.

Code Coverage Best Practices

But, you can deploy a Trigger with less than 75% coverage, for some unforgivable reason…

Sad cat

Let’s say we just got started and we have a class that is 100% covered. If we deploy a trigger that has less than 75% coverage, but does not decrease the average below 75%, it may deploy.

Total lines = 100
Total coverage = 100%
Deployment:
Trigger lines = 50
Trigger coverage = 25%
Total coverage = 75%

However, will create inevitable problems with maintenance and extensibility! As the code base grows the code coverage might decrease. If 75% is the goal it will fall short, and likely at the worst of times. Additionally, as the Trigger expands it will be come more difficult to test, the logic will get more complex and it will become more expensive and less pleasant to maintain.

Here is the situation I am in: Developers kept adding to a Trigger writing highly coupled, long methods. These lengthy conditionals can’t be unit tested without major refactoring (and this controls critical systems) and after 36 hours of writing tests I can only get the coverage up to 65%.

So here’s a microcosm of our org:

Total lines = 100
Total coverage = 75%
Deployment:
Trigger lines = 50
Trigger coverage = 65% // this is a 200% increase in coverage
Total coverage = 72% We can't deploy anything, even the code that iss already in production!

I’ll repeat that for emphasis: Our code that is in production won’t even deploy to production!!!

If we, as developers, take the time to test properly, while the logic is fresh in our heads, we will save ourselves, and future developers a lot of time and frustration. You should aim for 100% coverage and land upwards of 95%.

There’s a saying that developers are lazy. It’s meant as a sort of quip, but unfortunately, I am finding to be quite literal. Don’t be a slack jawed, mouth breather who writes crappy code that every hates to work on.

You can do better. We can all do better.

Confident, encouraging baby

--

--