testing

Testing Rules

Test Structure

• Arrange-Act-Assert: set up data → call the thing → check the result. Consistent structure makes every test scannable
• One behavior per test — multiple assert calls checking the same behavior is fine (assertThat(user).hasName("Alice"); assertThat(user).isActive()). Multiple unrelated assertions is not
• Test names describe the scenario and expectation: returnsNullWhenUserNotFound, throwsWhenEmailIsDuplicate — not test1, testUser, or shouldWork
• Tests must be independent. If reordering tests breaks them, you have shared mutable state — a test that only passes after another test runs is two bugs

What to Test

• Test behavior from the caller's perspective, not implementation details. "When I call createOrder with valid items, I get an order with the correct total" — not "createOrder calls calculateSubtotal then calls applyTax then calls saveToDb"
• Edge cases are where bugs live: empty collections, zero/negative values, null/undefined, boundary values (off-by-one), Unicode, very long strings, concurrent access
• Error paths are as important as happy paths — test that invalid input returns the right error, not just that valid input works
• Don't test framework/library code. If you're testing that Array.sort() sorts, you're wasting time. Test YOUR code's behavior when it uses the sort result

Mocking Strategy

• Mock at boundaries: HTTP clients, databases, file system, clocks, randomness — things that are slow, non-deterministic, or have side effects
• Never mock the system under test. If you're mocking half the class to test the other half, the class is doing too much — split it
• Prefer fakes over mocks when the boundary is complex: an in-memory repository that implements the same interface is more realistic than 20 mock configurations
• Verify interactions only when the interaction IS the behavior: "send email to user" needs verify(emailService).send(...). "calculate total" does not need verify(calculator).add(...) — check the result instead
• Mock return values for queries, verify calls for commands (CQS principle applied to test doubles)