Testkits: Design idioms and practices

A talk given at the Java.IL October 2019 meetup in Tel-Aviv

Modern-day software is usually built by multiple teams with well-defined domain boundaries. This is true of back-end systems (where microservices reign supreme), large web applications and virtually any system that's sufficiently successful. We opt for highly granular and highly interdependent designs, with the promise of letting teams make products independently. If that value is to be realized, however, teams need a consistent and reliable way of testing against their dependencies; this is where testkits come in. In this short talk we'll cover what testkits are, what makes a testkit useful (hint: ergonomics), and showcase a few common approaches and antipatterns.

Transcript

1. Testkits: Design idioms and practices Lightning talk at Java.IL Tomer Gabel, October 2019
2. Testing 101 • A question for the ages – You have a service – It has a dependency – How should you test against it? • Many answers – Use mocks – Test against staging environment – Test against actual implementation Service Dependency Library
3. One Approach • A testkit encapsulates the dependency • Can provide some or all of: – Lifecycle management – Drivers, hooks and probes – Data factories, utilities System Under Test Dependency Driver Setup Tear- down Fixture Test 1 Test 2 … Test N
4. The Ideal Promises • Fully self-contained • Explicit compromises: – Data durability – Multi-threading • Adds value for testing – Drivers – Probes – Matchers Implications • In-process/embedded • In-memory or ephemeral • Conforms to same specs • Coupled to infrastructure – JUnit rules – Hamcrest matchers – Etc.
5. EXAMPLE TIME
6. The Demo App ? Event Store Site Service Site Materializer Stored Events Snapshot Snapshot Store Base Snapshot Snapshot Strategy Persisted Snapshot
7. The Demo App Site Restorer Event Store Site Service Site Materializer Stored Events Snapshot Snapshot Store Base Snapshot Snapshot Strategy Persisted Snapshot
8. NOW FOR CODE https://tinyurl.com/event-sourcing-example
9. Best Practices • Drivers should not refer to implementation – Except the public API, if any • Avoid reset functionality – Hard to reason about – Prefer truly isolated* tests! – Respawn testkit if necessary * Isolated (adj): “having minimal contact or little in common with others” -- Oxford
10. QUESTIONS? Thank you for listening tomer@tomergabel.com @tomerg On GitHub: https://github.com/holograph This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.