Spock: Up and Running

Chapter 4. Managing Resources

So far, the User and Message classes in the Squawker application have existed only in memory. We’ve specified some of the behavior, but ultimately, the data itself is going to need to be persisted somehow.

How (Not) to Approach Persistence Testing

Testing persistence is one of the most frequently encountered types of integration test. If done incorrectly it can mean death to a suite of tests because they will run slowly and be incredibly brittle.

One of the most common antipatterns encountered is to test everything by reference to a single monolithic fixture containing an ever-growing volume of data that attempts to cater to every corner-case. The fixture will soon become the victim of combinatorial explosion—there are so many combinations of entities in various states required that the sheer amount of data becomes overwhelming and impossible to monitor. Tests based on monolithic fixtures tend to be replete with false moniker testing—“I know the pantoffler widget is the one set up with three variants, one of which has a negative price modifier and is zero-rated for tax.”

If any kind of write-testing is done, it’s almost certainly going to mean restoring the database between each test. Given the complexity of all the foreign-key constraints in that huge fixture, it’s going to be a practical impossibility to do that in any other way than by truncating all of the tables and setting everything up again. Before you know it, the test suite takes hours ...