Developing tests is a topic often overlooked in the process of developing software. The workload required to create and maintain them, the amount of boilerplate code that is necessary to check simple functionalities and the lack of clear benefit are some of the reasons why people tend to turn away from testing.

What are tests and why do we need them?

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.

Why are tests important?

  • Tests ensure the baseline quality of your software
  • Creating tests forces you to think about how the functionality you created will actually be used
  • Well written tests reduce the cost of maintaining software

Why isn’t everyone writing them then?

  • Tests are hard to create. They require a much more thorough approach to figuring out how the functionality being developed could be used, which by itself is a challenge. The difficulty of writing, and the sheer amount of boilerplate code required tends to hinder the quality of their code and makes maintaining them a hussle.
  • Large number of different tools required to actually develop them

Spock Framework

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 🙂