Approval Testing is well known as a good approach for getting Legacy Code under control. Did you know it can also be used in new development as part of a BDD process?
I expect you’ve played this game “4 in a row”? The board is a vertical grid and players take it in turns to drop coloured tokens in the top. The first player to get a row of 4 tokens in their colour wins. A colleague of mine, Olof Bjarnason, has been having fun implementing this game with Python and trying out an unfamiliar design approach. I worked with him on it and you can find the code on GitHub.
The picture shows a game that is in progress. When you click the mouse, the coloured token drops to the lowest available space in that column. As you can see, red has missed at least one opportunity to win already, and yellow is poised to take victory this move.
Think for a moment. How would you test that? And how would you develop this game using Behaviour Driven Development? Let’s work through this example and talk about how to do it with BDD and an Approval testing approach.
Early in the development of this game you’d perhaps hold a workshop and invite developers, testers and business stakeholders. What kind of examples would you come up with? I’m imagining a whiteboard with a number of sketches looking a little like this:
The point of this section is to ensure relevant details of the game are working properly as each player places their pieces.
In the “Formulation” part of BDD the tester and the developer discuss what they want to check in the test. They can decide together what details of the position to log. What colours and mouse clicks and sounds are important to include in the checked output. This discussion begins before the program code is written, but the final version of the test is not finalized until the ‘automation’ part is done, and they can ‘approve’ the result.
The developer begins the automation work with a good idea about what the formulated printed output should look like. They need to write some test code to simulate clicks and print the agreed details of the game state. I haven’t included that code here – it’s like the step definitions you have in a SpecFlow or Cucumber test. Ideally you shouldn’t need to read that code to understand what the test checks for. If you’re interested, the test code is in this file on GitHub.
In BDD the focus is on enabling better conversations with stakeholders. That is still true when you use an Approval Testing approach. You want to create executable specifications that are readable to all parties. In this example we showed the language you use can be a kind of textual printout or log showing the important actions and outputs of the system under test.
This approach is not exclusively for games and toys like four-in-a-row. I’ve used Approval testing in a BDD process on various business software applications too. The sweet spot seems to me to be on applications where the domain is visual. It matters what it looks like. Start with sketches in the example workshop and then design tests that check a relevant level of visual detail. Automate by building a printer and using Approvals to check the printout.
Approval testing tools are available for many programming languages. This four-in-a-row example is fun to play with and suits this technique. Why don’t you have a go at it coding it yourself?
Join Emily this November in her upcoming remote course Agile Development techniques: Approval Testing, to learn more about this topic.
About Emily Bache
Emily Bache is a Technical Agile Coach and long-term proponent of agile development practices like Test-Driven Development. She is a published author with Pluralsight and wrote „The Coding Dojo Handbook“ for which Emily is currently writing a follow up book called „Technical Agile Coaching“.