Unit testing with Java, day by day
For A Java developer who can read classes, methods and exceptions, and wants to design and review tests that deserve trust — especially when AI drafts the implementation or the test. · 16 days · Tech
The days
- 0Build your test benchBy the end you can run one JUnit test from Maven and deliberately make it fail.
- 1Decide what one test provesBy the end you can state the exact behavior a unit test proves and expose one behavior it leaves unprotected.
- 2Name behavior before implementationBy the end you can structure a test around setup, action, and observation and give it a behavior-focused name.
- 3Choose assertions that reveal defectsBy the end you can select an assertion and observation that distinguish a correct result from a plausible wrong one.
- 4Test boundaries, not random examplesBy the end you can derive boundary and equivalence-partition cases from a written rule.
- 5Test failures as behaviorBy the end you can test exception type/message and prove the failing operation did not produce a forbidden result.
- 6Keep tests independent and deterministicBy the end you can remove shared mutable state, ordering, randomness, or environment dependence from a test.
- 7Parameterize rules without hiding casesBy the end you can convert repeated rule examples into a readable parameterized test while keeping boundary meaning visible.
- 8Choose the unit boundaryBy the end you can decide whether behavior belongs in a unit test, broader test, both, or no direct test.
- 9Shape classes for unit testingBy the end you can refactor a mixed class into a decision core and side-effect shell with explicit dependencies and observable outcomes.
- 10Choose the lightest test doubleBy the end you can distinguish fake, stub, and spy and choose the least powerful double that answers the test question.
- 11Test outcomes, not choreographyBy the end you can reject interaction-heavy tests when a stable state or returned outcome proves the behavior.
- 12Control time without sleepingBy the end you can inject `Clock` and test time-based rules without using the wall clock or `Thread.sleep`.
- 13Read coverage as a questionBy the end you can use JaCoCo line and branch signals to ask for missing behavior without treating a percentage as quality.
- 14Review AI-generated testsBy the end you can audit generated tests for oracle copying, happy-path bias, implementation coupling, missing assertions, and tests that cannot fail.
- 15Break the suite before trusting itBy the end you can complete a mutation-style capstone by inserting plausible defects, observing survivors, and strengthening the smallest useful tests.