Testing has been part of the software delivery lifecycle since… forever. Now, Agile methodologies make testing part of everyone’s responsibilities. But despite this, despite big steps forward with TDD, BDD, and other approaches which bring automated testing to the forefront of the development process, many developers still behave as if testing is a second class citizen.
What can you do to help developers a) write tests b) write meaningful tests and c) write readable tests?
Trisha Gee shares her experiences of working in a team that wanted to build quality into their new software version without a painful overhead – without a QA / Testing team, without putting in place any formal processes, without slavishly improving the coverage percentage.
The team had been writing automated tests and running them in a continuous integration environment, but they were simply writing tests as another tick box to check, there to verify the developer had done what the developer had aimed to do. The team needed to move to a model where tests provided more than this. The tests needed to:
* Demonstrate that the library code was meeting the requirements
* Document in a readable fashion what those requirements were, and what should happen under non-happy-path situations
* Provide enough coverage so a developer could confidently refactor the code
This talk covers how the team selected a new testing framework (Spock, a framework written in Groovy that can be used to test JVM code) to aid with this effort, and how they evaluated whether this tool would meet the team’s needs. And now, two years after starting to use Spock, Trisha talks about how both the tool and the shift in the focus of the purpose of tests has affected the quality of the code. And, interestingly, the happiness of the developers.