In my time at Pantheon I have worked with a lot of agencies on refining their development workflows and continuous integration processes. One common thread I've noticed is that most agencies think they are behind the curve on automated testing. Everyone else is talking about automated testing for their client projects, so everyone else must be doing it, right?
The Struggle Is Real
In practice, fitting automated testing into client projects is a struggle for most Drupal and WordPress teams that consider it. Keeping your development team current in the shifting best practices of WordPress and Drupal is hard enough. Throw in PHPUnit, Behat, and other testing frameworks and it can be overwhelming.
The end result is that many agency developers tinker with tests but rarely bring them into client projects. When nearly every day is is spent executing tickets to prepare for your end-of-sprint demo, it feels like there is no time for new tools.
Demo Driven Development
If you find yourself in this situation, embrace it. Take time at the beginning of a sprint to write out (in plain English) how you will demonstrate each of the features or user stories in the sprint. In my last job at Palantir.net, we called this process Demo Driven Development. Of the five main benefits you can get from automated tests, Demo Driven Development can help move you forward on at least three of them.
Documenting the code's behavior. The demo script you write for yourself can serve as a starting point of documentation for the website you are building. Imagine the client expects documentation on how to add news articles to the homepage. Such documentation is easy to write if you already have text written telling yourself how to demonstrate that feature.
Provide design guidance. In Drupal and WordPress the saying goes: "There's a module/plugin for that." In practice, for any feature you might build there are usually a dozen tools that could be used. Which implementation details matter? Does a given feature call for a one-off specifically coded admin form or a generic entity type? If the answer does not matter much for how you will demonstrate the feature to your client, it may not be worth sinking lots of time into finding the perfect solution.
Verifying the code is working correctly. When you open a pull request, or otherwise communicate to your team that the feature you have coded is ready to go, the demo script will help the review process. When you write your demo script in plain English right into your Jira ticket, or other relevant place, your teammates can check out your branch and just try it. The script for how you will demonstrate the feature greatly helps your teammate test the branch and verify its correctness.
The plain English scripts spelling out your end-of-sprint demo can help bridge your team to automated testing. At DrupalCon Baltimore I mentioned Demo Driven Development in my presentation "Bending Behat's Benefits." Little by little, a team can start picking high value feature demonstrations and converting them to Behat tests with a bit of rewording. By doing so, you will start to get even more of automated testing.
Running automated Behat tests can prevent future regressions and support refactoring, the two remaining future-focused benefits of testing. When the present, not the future, is your focus, Demo Driven Development can be your onramp to more robust testing.
You may also like: