test-driven-development

Follow the Red-Green-Refactor cycle: write a failing test describing the expected behavior, write the minimal code to make it pass, then refactor while keeping tests green. Run tests after every refactor step to confirm nothing broke.

Use the Prove-It Pattern: write a test that demonstrates the bug and confirm it fails before touching the fix. Then implement the fix, verify the test passes, and run the full suite to check for regressions.

Prefer real implementations first, then fakes like in-memory Room databases, then stubs, and mocks only as a last resort. Reserve mocks for slow, non-deterministic, or uncontrollable dependencies such as external network APIs.

A behavioral test executes real logic and asserts on a value or observable outcome. Boilerplate template tests, mock-verification tautologies, and assertion-less label checks count as zero coverage because they pass even when the real implementation is broken.

Skip TDD for pure configuration changes, documentation updates, and static resources like images or drawables that have no behavioral impact. Everything else, including bug fixes and edge case handling, should start with a test.