Apex Code Development You need to sign in to do that
Don't have an account?
mhamberg1 Lesson Learned: Breaking test coverage of production code
I wrote a custom app and tested the code and everything was fine. I pushed the code to production and it was working and in use.
I wrote new code in our Sandbox later on for another process, when I ran a test of that code, I had enough coverage of it and I was ready to push that code to production as well. However, when I tried to move the new code to production using Eclipse, all of a sudden one of my old triggers that was already in production said it had 0% test coverage. This made my new migration fail. It was a trigger that I had already tested and it previously had 100% test coverage. Since you can't change triggers in production, it was extra baffling.
After a few hours of testing and spinning my wheels, I realized that in Production we had created a new validation rule that we didn't have in the Sandbox. Because of the new validation rule, the Test class that was previously working was not allowed to fire off one of my triggers thus invalidating a working triggers' code coverage (even though the trigger still functioned fine in production).
The moral of the story is that when you add any new code to production, it reruns a test of ALL your code (including previously added classes). If you've added anything in production that might affect some of your triggers, it can break your test coverage percentage.
When developing in a sandbox env - you want to make sure the sbx is an accurate copy of production.
"If you've added anything in production that might affect some of your triggers, it can break your test coverage percentage."
Tests allow you to validate behavior. If your tests are failing in production - you should definitely investigate. And in your case, the errors were harmless - but you should absolutely address this by redeploying tests that respect the new configuration. As a best practice, I would recommend validating your sbx is an exact copy of production - this way you would have identified the test failures in sbx - rather than on deploy.