Question

Regarding contract tests, would you group both expectation and assertion checks together or would you keep them as separate checks along the lines of each separate line in your talk?

Discussion

I assume that, by “each separate line in your talk”, you refer to the four arrows that I draw between the client and the supplier:

1. The client asks the supplier questions. (Client uses interface syntax.)
2. The supplier “accepts” those questions. (Supplier implements interface syntax.)
3. The supplier answers those questions. (Supplier implements interface semantics.)
4. The client “can understand” the answers. (Client uses interface semantics.)

In short, no, I don’t feel the need to organize collaboration and contract tests according to these lines—at least not in the sense of filing them into a directory structure on a file system based on these categories. Since I know how to search for the tests I need, I rely on being able to search for them, but if tagging the tests would help me find them later, then I would do that. If I needed more-detailed traceability information due to governance needs, then I would provide that in whatever form will help the auditors do their work.

When I have free choice, I tend to organize collaboration and contract tests by layer: I use collaboration tests (the “expectation checks”) to implement the client (which includes designing the collaborators’ interfaces), then I use contract tests (the “assertion checks”) to implement the collaborators in the layer below. I often organize the tests by layer, naming the collaboration tests for the client they focus on and naming contract tests for the interface and implementation they focus on. I might organize the tests into packages or modules by layer, but I don’t consider this particularly important. I tend to let this happen naturally in context, rather than assuming that I need a certain strategy. I fall back to first principles and let my feelings about the names guide me.

References

J. B. Rainsberger, Integrated Tests Are a Scam: Articles.

J. B. Rainsberger, “‘Integration Tests are a Scam’ is a Scam”. A reminder of how I use integration tests and integrated tests, so that you might better understand me.