That question, and much more, were the topic of Lunch and Learn session in Pretius about ‘ Testing software using the Spock Framework’.
The first segment of the meeting was dedicated to the general area of testing. Things like the importance of testing, overview of the different kinds of tests and ways of utilising tests to their fullest extent were the topics of discussion.
Spock is a framework created to solve most of the issues mentioned above. It uses Groovy, which by itself reduces the boilerplate, and expands upon it with it’s own mechanisms and syntax, further clearing up the unnecessary clutter. Spock uses human readable blocks (like “given:”, “when:”, “then:”) which, in conjunction with their comments and Groovy’s “string-as-a-signature” function naming, make the tests easy to read and understand, even without much technical knowledge. This in turn allow for tests to be designed by an analyst and forwarded to the developer to create:
The above test is a valid, working example (although it wouldn’t do much without any code 😉 ) and showcases how easy it actually is to design and set up basic tests using Spock.
The framework has integrated tools for Interaction Testing. Namely, mocking and stubbing objects, and asserting function and method calls. It also allows provides a convenient way of creating Data Driven Tests, by introducing Data Tables. Spock also features perhaps the most informative assertion failure message I’ve ever seen:
Everything that would normally be searched for using a debugging tool is clearly visible at the first glance. The feature also provides information on differences between strings by the letter. Thanks to that, I never have to spend 20 minutes trying to figure out why a test I’ve written does not work, all while missing an obvious typo or a simple logic mistake.
The ease of use, the excellent readability, an almost complete lack of boilerplate code and a wide variety of tools all integrated into a single framework make Spock a pleasure to use, which for me is enough reason to start integrating tests into every system I develop.
After exhausting the topic of Spock and its various features the presentation moved briefly to some groovy tips and tricks and ventured into the topic of Test Driven Development.
The idea of TDD is basically to write tests first and code later. By beginning the development process with tests, the programmer is forced to conceptualize the functionality and application of the code in detail before anything is created. When the time to develop comes, the idea of how the code is going to work and the interface it’s going to provide is usually clear and organized. That helps avoid some otherwise unforeseen pitfalls and helps the developer abstain from creating needlessly convoluted solutions, which minimizes the amount of refactoring needed on the way forward.
The presentation ended with some insight into code coverage and automatic code analysis tools like JaCoCo and SonarQube. These tools are very useful for keeping code in a high standard. They can be set up to automatically analyze and report on every release, merge or even commit, depending on what is needed. They provide statistics like % of code covered with tests, duplicated code and even report security risks and best practice violations.
After the presentation was finished, the time has come for the most important part of the learning experience – a lively discussion about the freshly learned topics with a plate of fresh, hot, delicious pizza 🙂
