If you've been around the block a few times you already know that testing is IMPORTANT. If you've tasted the sweet sweetness of a test-first style of development and continuous delivery, you already know that automated testing is also IMPORTANT.
But how do we write our tests? Do we treat our test harness code with the same 'clean code' standards as our application code? Is it MAINTAINABLE?
One way to address test maintainability is by using the practice of Behavior Driven Development. BDD is a shift in thinking from building tests around your application to identifying the desired behaviors of the application. Each behavior is described in a human readable fashion along with its acceptance criteria. The desired behaviors of an application could be thought of as the requirements. Although its easy to argue that BDD is just using fancier terms for similar Test Driven Development concepts, the results in practice have far reaching effects, one of which we'll discuss below.
In brief, Separation of Concerns is the keeping of conceptually different aspects separate and loosely coupled within an application. A good example of this would be the Model View Controller pattern. MVC separates the visual representation away from how the information is modeled as well as from the logic that manipulates it.
These separations are powerful when applied to testing. Who has the best understanding of the micro and macro requirements of your project? In many cases this is a business analyst or product owner. Is it intuitive for the business analyst or product owner to communicate to the developers via test implementation code? Probably not.
Instead, in the spirit of Separation of Concerns, the requirements should be documented without having to know how their acceptance tests will be implemented. In line with the Separation of Technologies principle the requirements should be written in a broadly understandable domain specific language for the benefit of all stakeholders. The implementation code-behind, loosely coupled to the requirements document, should be built in a coding language most suitable to the developers.
Not only does the concept foster communication among team members, Separation of Testing Concerns through the lens of Behavior Driven Development opens a much larger Can Of Effectiveness:
A large amount of thought work has been put into the Separation of Testing Concerns in BDD. Using the well developed Given/When/Then text structure of the Gherkin behavior language we can generate living test documents that are easily understood by anyone. These documents can also be interpreted and executed in a rigorous manner. Since it’s a descriptive, not a development language, Gherkin is not reliant on any one implementation. Behavior Driven Development tools such as Cucumber, SpecFlow, Behat, and JBehave all employ Gherkin to support human readable testing in their respective coding languages.
Note: This article doesn't cover the specifics of the Gherkin language. That is left up to the many great articles already written such as these from Dan North and Stephan Kurniawan, and Vieira et. Pufal.
Current requirements always change and old requirements are often forgotten. Ensuring that the documentation of these requirements remains as simple and focused as possible means that they must be easily located and understood by future analysts and developers alike. Though the code-behind for test implementation may be difficult to search through, the test specification will not, allowing for improved MAINTAINABILITY as the software matures.
What do you think? Do you and your team find the above to ring true, to be challenging, or to be completely foreign? If this sparks a response I strongly urge you to bring up the topic of Separated Testing Concerns with a friend or team mate.
It's rewarding to find out what others in our field have to say as well. Here's a bunch of respected professionals writing about subjects touched on in this article.