Chapter 8. Spock features for enterprise testing
This chapter covers
- Using Spock annotations that are helpful in enterprise testing
- Refactoring large Spock tests
- Testing legacy code with spy objects
One of the good qualities of a flexible software tool is the ability to adapt to any software situation, especially the corner cases that appear in large enterprise projects. Enterprise projects often come in large code bases (think millions of code lines), have an endless stream of requirements, and more often than not contain legacy modules that can’t be changed for political or technical reasons.
Chapter 1 showed that Spock is a holistic testing solution that will cover your needs regardless of the size of the application and whether you work solo or as part of a large team. A bigger code base always amounts to extra complexity on all fronts (compilation, documentation, and delivery), and it’s good to know that Spock has you covered even when your needs are off the beaten path.
This last chapter of the book shows you extra Spock features that are geared toward large enterprise projects. These techniques are in no way essential for Spock testing, as they solve specific problems that you might not encounter in your current project. Before employing any of the advice in this chapter, make sure that you indeed suffer from the specific problem being discussed. More importantly, the last section explains spy objects, a feature that I strongly advise you not to use, unless this is your last resort.
This chapter has three distinct parts, listed here in roughly the order I expect you to use them in your Spock tests:
- Using Spock annotations for time-outs, exceptions, conditional test running, and so on
- Refactoring of large then: blocks that contain assertions or interactions
- Using spies as partial mocks (continuing fake objects from chapter 6)
Spies are a controversial feature (not just with Spock[1]), so make sure that you understand the implications of using them in your unit tests (and what that means for your Java production code). Use of spies implies that your Java code suffers from design problems, as you’ll see in the last section.
Mockito’s official documentation also has a huge warning against the usage of spies.