Software Testing

A test is an evidence-producing experiment with a declared boundary, oracle and environment. A useful strategy spends the cheapest credible test on each risk, then reserves broad end-to-end checks for behavior that smaller scopes cannot prove.

A durable unit test isolates its own fixture, performs one meaningful action, and checks externally meaningful behavior with an independent oracle. Its value is fast, specific feedback that survives refactoring rather than maximum isolation or assertion count.

TDD is a micro-cycle for discovering behavior and shaping interfaces: make one missing example fail, implement the smallest coherent behavior that passes, then improve structure while the behavior stays protected. It is useful where examples are predictable and fast tests compose into confidence, not as a universal coding ritual.

A test double replaces a collaborator for a specific test purpose. Dummies fill unused parameters, stubs provide indirect inputs, spies record interactions, mocks verify expected interactions, and fakes implement a cheaper model whose drift from production is an explicit risk.

Integration tests prove behavior that exists at a real boundary: SQL translation and transactions, broker delivery, filesystem semantics, wire formats or third-party protocols. They need production-equivalent dependency types, isolated state, real migrations and evidence that distinguishes readiness from correct behavior.

Reliable async tests control time, wait for an explicit completion or quiescent state, and separate logical ordering from data-race detection. Sleeping and polling merely hope that a schedule occurred; virtual clocks, deterministic schedulers and bounded synchronization make the schedule part of the experiment.

UI automation should verify a small set of user-visible journeys through stable semantic locators, isolated state and condition-based waits. Functional browser tests, end-to-end scope and visual screenshot comparison are separate dimensions with different oracles and failure evidence.

Acceptance examples turn stakeholder rules into observable scenarios; BDD is the collaborative discovery process that produces them, and Gherkin is one syntax for executable examples. Good scenarios describe business behavior independently of UI procedure and run at the cheapest boundary that preserves the rule.

Characterization tests capture what an existing system actually does before risky change, while seams provide controllable observation and substitution points. The technique creates a change detector, not proof that current behavior is correct; intentional fixes require explicit decisions about which captured outcomes remain contracts.