Growing Object-Oriented Software, Guided By Tests (chapter 25)

How do we test persistence?

Clean up the persistent state at the start of a test, not at the end.

If the test fails we can inspect the current state of the DB - If we clean up straight after the test, this information will be lost.

We use this technique to isolate tests from each other.

Make tests transaction boundaries explicit - we should be able to see exactly where/how a database transaction is being initiated. Consider moving this action to a separate object.

We can use DAO (data access objects) and the repository pattern, but the authors caution against using these technical terms to name objects in our codebase.

Be aware that testing the persistence layer will be a lot slower than unit tests. We should use persistence tests as part of the integration/end-to-end testing cycle. Unit tests can be used to test the interface of our persistence objects, but cannot give us a full understanding of how the system works when backed with a separate persistence layer.

Haven’t made many notes on this chapter… I think I will revisit this later.