I hope we can all agree that testing is an important part of the software development process. (Whether or not you actually do it is another story.)
I dunno about you, but sometimes outstanding tasks cause me some anxiety. And in a weird reversal of logic sometimes these tasks get avoided because even the thought of digging into them also causes anxiety. So not doing them? Problem. Trying to start doing them? Problem. You’re anxious if you do and anxious if you don’t. So you just try to forget all about it and throw it on the farthest back burner you have until you absolutely have to get the work done.
I feel like testing is like this for some people. Oh they know they should be doing it. They figure they’ll get around to doing it someday. But <insert logic and excuses> so we aren’t right now. And then development happens and you dig yourself in deeper. And then you have a “finished” application and it’s not super stable, and it breaks, but how do we even start adding tests to something so big and complicated?
The phenomena of jobs that are too big / messy / stressy to actually start picking away at are super common and not isolated to software. It could be a room in your house that needs to be cleaned. It could be your health. It could be a relationship that has deteriorated. The bottom line: whatever it is is never going to get better until you start investing some thought and energy into overcoming that anxiety and intentionally making it better.
Let’s talk about what that means for testing!
Where to start
This is the thing that, in my experience, is most challenging. When you have a big mess and you have to dive in somewhere… there often is no good place to start. You just have to start.
In terms of automated testing, this is my usual recommended approach:
do you have features on your site that might cause legal action if something goes wrong with them? examples might be a data breach or regulated features.
do you have any features that are mission critical that would result in financial loss?
do you have any features that might significantly impact the end-user experience?
Of course, it’s easy to say “all of our features are important.” I don’t disagree! But if you use the above litmus test, hopefully that helps prioritize. And if not (if they’re all important), then who cares. You don’t have any test coverage now. You aren’t going to be worse off than you are. Pick a place, and start.
How to Start
This is, believe it or not, a pretty easy answer. If you are going to add automated testing to your platform you need a few things:
Continuous Integration (of some variety)
Representative Drupal site with config + content
Test cases
Of course, this list assumes some things. For CI to work you need a task runner that can execute the proper tasks. These tasks have to be run in a container that is similar to your production environment.
You can’t test a site that isn’t representative (or identical) or your production site. So having the right stuff in the right place at the right time? Pretty important.
And of course, you need actual test cases in your favorite testing framework. Typically, this is Behat / PHPUnit / Nightwatch but could be anything. Anything is better than nothing!
If you don’t already have some of these things… this is where you start. Before you tie yourself in knots worried about the actual testing backlog focus on building out your CI pipeline. Focus on getting Drupal up and running in CI.
Types of Tests
I typically talk about a few types of automated testing. It’s important to use the right tests for the right job. It’s also important to know both what you ARE testing and what you are NOT testing with a given test case.
Functional
Unit
Visual
Code Quality
Keep in mind that each type of testing has a different level of effort to implement, type of effort to implement, and value. For example, automated code quality testing is typically very easy to implement. While I advocate strongly for code quality scans, they don’t tell you a lot about the functionality of your platform.
Code quality scans are actually one of the easiest tests to put in place (and where I recommend starting). Usually, you should:
test each coding language you are writing (e.g. PHP, Twig, YML, JS, SCSS, etc.)
test for deprecated code
test for valid dependencies.
Next I would focus on functional testing. This should be done with ONE framework (pick your poison, Behat, PHPUnit, or Nightwatch are common). Pick a feature, add your test, make it pass, then rinse and repeat!
In Conclusion
OK, yes it’s so much easier to do automated testing as you go. YOU SHOULD DO AUTOMATED TESTING AS YOU GO! But if you don’t, you’re not alone. So many projects don’t have any automated testing at all. Acknowledge that the situation isn’t ideal. Then come up with a plan to make it better. Do it piece by piece and attack it just like you would any other technical debt.
Good luck!