Should I test that?

Product decisions

Whether prototypes, MVPs, internal tools, experiments and code under deadline need tests at all.

Most asked

  1. Should I test a prototype?No
  2. Should I add tests to legacy code?Yes
  3. Should a solo developer write tests?Yes
  4. Should I write tests when requirements keep changing?Yes
  5. Should I write unit tests for games?Yes

Yes9

  • Should a solo developer write tests?Yes

    Yes, a solo developer should write automated tests for the paths that customers depend on, such as signup, the core action and every saved record, and run them in CI on every push.

  • Should a startup write tests?Yes

    Yes, a startup with customers should test the paths that keep them, such as signup, login and the core action, in CI, and check screens that change every week in the browser instead.

  • Should I add tests to legacy code?Yes

    Yes, add tests to legacy code before you change it: characterization tests that record what the code returns today, then tests for the new behaviour, all in CI; do not set a coverage target for the whole codebase.

  • Should I skip tests when the deadline is tight?

    Yes, cut the tests to the minimum under a tight deadline: keep one test of each main path the new feature adds and every test of code that charges money or checks access, and leave edge cases until after the release.

    Code under test: Yes

  • Should I write tests before the beta release?Yes

    Yes, before the first beta invite, write automated tests in CI for the main paths that beta testers run and for every endpoint that saves their data, and check screens that beta feedback will redesign in the browser instead.

  • Should I write tests for an MVP?Yes

    Write one automated test of the MVP's main path, from signup to the core action, and skip unit tests and coverage targets until the MVP handles money or private data.

  • Should I write tests for side projects?Yes

    Yes, write one or two tests of the core logic of a side project that other people use, run them on every push, and leave the pages and glue code untested.

  • Should I write tests when requirements keep changing?Yes

    Yes, write tests when requirements keep changing: one API-level test for each rule the client states, changed in the same commit as the rule, and no tests of screen layout.

  • Should I write unit tests for games?Yes

    Yes, write one or two unit tests for the core rule of a game, such as its damage or scoring calculation, and playtest the movement, visuals and feel instead of testing them.

No2

  • Should I test a prototype?No

    Do not write automated tests for a prototype that only you change and click through after every change; list each shortcut you take, and add tests on the day the prototype gets its first real user.

  • Should I test throwaway code?No

    Do not write automated tests for throwaway code that only you run and then delete; check its output against one case worked out by hand, and add tests on the day someone decides to keep the code.