Test-Driven Development (Rails / Minitest)

Philosophy

Core principle: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.

Good tests exercise real code paths through public APIs. They describe what the system does, not how. A good test reads like a specification — "user can check out with a valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.

Bad tests are coupled to implementation. They test private methods, stub internals, or verify through back-door database queries instead of going through the application's own interface. Warning sign: your test breaks on a refactor but behavior hasn't changed.

See tests.md for examples and mocking.md for stubbing guidelines.

Test Types in Rails

Use the right scope for the job: