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?
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:
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.
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.