In June, I had the opportunity to attend Salesforce’s TrailheaDX conference. In one of the sessions, I gave a quick 5 minute “campfire” story. Here it is, in written form!
Attending Dreamforce this year? Join me on Tuesday, October 4th as a I teach you about the Dark Art of CPU Benchmarking with Dan Appleman. Look out for a recap post here shortly thereafter!
TrailheaDX Campfire Story
Not so very long ago, I worked on a managed package that had thousands of unit tests. Thousands! To care about ensuring that *all* code is functioning properly in such a large product is pretty cool, right?
Well, there was a problem. A few, actually.
If you wanted to run these unit tests in one of the development orgs, go get a cup of coffee. Actually, you might as well go get an entire pot because they were taking over an hour to run! How could they be taking so long?
The team set out on a discovery and realized that updating the Apex Test Execution options and unchecking the “Disable Parallel Apex Testing” setting brought the time down from over an hour to 15-20 minutes. We found a solution – what a relief!
However, our journey was not yet done. Imagine you’re out walking in the sweltering hot forest – your water is almost gone, there are several blisters on your feet – and you spot your final destination out in the distance. So you keep walking, getting ecstatic that this will be all over soon… but you’ve been fooled. While your final destination may appear to be close, you soon realize there are several more hills to climb and fallen trees and rocks to maneuver around.
When running the tests asynchronously, many tests would fail due to row locking issues. It was never the same ones, and simply ignoring the failures was not an option because it wasn’t sufficient to say “oh, well they just failed because of row locking, but we know the actual unit test does really work.” So now we had to figure out which ones failed and select those to re-run again. And sometimes some of those would fail, and we’d have to re-run the ones that failed a second time.
One day, a developer stumbled upon the Salesforce Winter ‘16 release notes and made an interesting discovery. If you run unit tests through the Developer Console instead of from the Apex Test Execution page, there’s an option to re-run the failed unit tests! This means that you don’t need to manually re-run the classes that failed. Even better, you can select to run only specific test methods within a given test class instead of running the entire class.
This was great news. Developers everywhere rejoiced. While running so many tests asynchronously still causes row locking issues, we had better tools to enable us to confirm they all worked as expected.
So, what can we learn from this? First and foremost, read the Salesforce Release Notes – you never know what gems you may find. But don’t worry about remembering everything (because you won’t). You can always go back and re-read them later when it is more relevant for you – Salesforce doesn’t remove previous release notes. And even better, you can navigate the Salesforce Developer Documentation by release version as well!