Testing

Testing is its own engineering discipline, with its own pyramid, its own tooling stack, and its own failure modes. This section treats it that way — not as something tacked onto code, but as a thing you design, scale, and operate.

The material is organized by the questions you ask in practice:

• What should we test, and at what level? — strategy
• Why is our code so hard to test? — testable design
• How do we run these tests reliably and cheaply, every commit? — automation

Topics

Foundations

• Testing Strategy — What to test, at what level, and how to keep the suite fast and trustworthy as the codebase grows.
• Testable Code — Writing code that is easy to test, and tests that are easy to maintain.

The Layers

• Unit Testing — Structure, assertions, and the discipline of testing one thing at a time.
• Integration Testing — Testing components wired together; what to wire up, what to fake.
• E2E Testing — A thin layer that proves the whole stack works; how to keep it stable.
• Contract Testing — Catching service-boundary bugs without spinning up everyone's stack.

Specialized Techniques

• Property-Based Testing — Asserting properties that hold for all inputs; generators and shrinking.
• Mutation Testing — Testing the tests; deliberately breaking code to see whether anything notices.
• Performance Testing — Benchmark, load, stress, and soak — four disciplines, four questions.

UI-Specific

• Visual Regression Testing — Catching unintended UI changes by comparing pixels.
• Accessibility Testing — A layered discipline; what automation catches, what only humans can.

Operations

• Test Automation — Running the suite reliably in CI: pipeline shape, parallelization, flake management, coverage gates, reporting, and test data.

Scope and Boundaries

The split with code-craft/quality/ is deliberate: quality/ keeps the non-testing dev disciplines (code review, debugging, code-level performance). testing/ owns the testing discipline end to end.