TomerAberbach Adhere to these principles when writing tests:
Use arrange-act-assert with empty lines in between:
- Arrange: set up the requisite state and inputs
- Act: run the code that triggers the behavior under test
- 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