Authoring Tests

Adhere to these principles when writing tests:

• Use arrange-act-assert with empty lines in between:

  1. Arrange: set up the requisite state and inputs
  2. Act: run the code that triggers the behavior under test
  3. Assert: assert the expected outcomes

• Keep each test focused and independent of other tests unless you're testing an interaction between two behaviors or each test is expensive

• Prefer parameterized testing over multiple independent calls and assertions in the same test

• Test behaviors, not functions. A single function may exhibit many behaviors, and a single behavior sometimes spans multiple functions

• Write test names that describe the scenario and the expected outcome

• Avoid overspecifying tests. Rule of thumb: if changing the expected data in an assertion does not change the meaning of the test, then don't assert it

• Test the public API only, not implementation details

• Prefer real implementations and test doubles over mocks. Reserve mocks for I/O boundaries and third-party services. If you must use mocks, then mock only public APIs

• Extract well-named variables to split up and clarify complex test data

• Use helper functions to remove redundant details from the test body. Don't hide details relevant to the test in helper functions. Pass the relevant data into the helper function from the test instead

• Don't put logic in tests. Avoid conditionals and loops, and state inputs and outputs directly to avoid bugs in the tests themselves. If the logic is necessary, then extract it to a function and test it as well

• Do not write redundant change detector tests. If the test would break for any change in the code under test, then it's likely a change detector test