Testkits: Design idioms and practices Lightning talk at Java.IL Tomer Gabel, October 2019

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

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

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.

EXAMPLE TIME

The Demo App ? Event Store Site Service Site Materializer Stored Events Snapshot Snapshot Store Base Snapshot Snapshot Strategy Persisted Snapshot

The Demo App Site Restorer Event Store Site Service Site Materializer Stored Events Snapshot Snapshot Store Base Snapshot Snapshot Strategy Persisted Snapshot

NOW FOR CODE https://tinyurl.com/event-sourcing-example

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

QUESTIONS? Thank you for listening [email protected] @tomerg On GitHub: https://github.com/holograph This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.