I’m going to start this series about Unit Testing with a confession: I’m not actually a Salesforce admin. Please keep reading! I’m actually a developer who attends and speaks at admin groups and works alongside a crack team of admins every day.
So why talk about Unit Testing?
Our Success team are a smart bunch with a lot of experience and certifications between them. These posts and the talk which spawned them arose because we wanted to introduce them to subjects that are not on the admin learning track, but that we thought might be interesting and help with the work they do for our Support clients.
Support is a big part of our business, and we’ve inherited responsibility for a number of Salesforce orgs. Some of them arrived in tip-top condition. Others, older and with significant customisation, were less stable than we would like. They required significant developer time to repair broken Unit Tests, and issues highlighted by broken Unit Tests before any new work could commence.
In this series, I’ll talk (briefly) about what Unit Tests are, why we have them on the Salesforce platform, how to run them and what it can mean when they go wrong, but let’s get one key question out of the way first:
I’m an admin, what’s this got to do with me?
A totally valid question. As a Salesforce admin you’re already swamped with stuff to learn about: three releases a year, constant new features and acquisitions (Mulesoft? Tableau? Einstein? FSL?), not to mention all the community meetups and those blogs, feeds and podcasts that we’re supposed to keep up with; why learn about dev stuff as well? Well, because (drumroll please…)
Broken Unit Tests are a problem for everybody
It’s not just a hassle for the unlucky developer who gets to fix them, possibly years after they were written, and after anyone can remember why they exist at all (can you feel the anxiety? Yes, I’ve had to do this a lot…). Here are a few reasons why:
They can prevent us from deploying new work
Look familiar?
Ok, so I know that you can deploy configuration changes without running your Unit Tests, but it’s time to think about whether you should. My argument is that we should be running our tests more often, and especially when deploying new features.
They can signify deeper problems in your Salesforce org
This is crucial: fixing broken Unit Tests will not fix the problems that they highlight in your org, any more than fixing a broken fire alarm will put out a fire in your house. Unit Tests are designed to fail if the functionality they are testing no longer produces the expected results, and it’s up to us to find out why.
They can be (very) time-consuming to investigate and fix
As we’ll see later on, some test failures can be repaired by adjusting them to anticipate a small change in configuration. Others, however, have much more complex causes that require investigating changes to platform features, governor limits, managed packages and what may appear to be completely unrelated functionality. This can take a while, and leads me to this:
Developer resources are expensive
Everybody in our ecosystem is necessary and valuable, but Salesforce developers are not easy to come by (as you’ll know if you’ve ever tried to recruit them). Not only that, but our time tends to be block booked for specific projects many weeks or even months ahead. Taking a developer away from their scheduled work to fix Unit Tests can be awkward, which suggests that the ability to identify, and perhaps triage, errors with testing is a very good skill for an admin to have.
TL;DR
Thanks for making it this far! That got the “why” out of the way, so next time I’ll move on to what Unit Tests actually are, how you can run them, and how they can go wrong…
