NOTE: This guide is work in progress. This is just the layout to be properly written.
Do's
- Write tests as 3 separate blocks (data preparation, execution and expectation)
- Write boring tests. The most boring a test is the better.
- You should only use abstractions if there is a very good reason.
- It's ok to have repetition. Copy & paste is allowed in tests.
- Only extract to helper methods when it makes sense.
- Of course some repetition is helpful to extract large payloads for example.
- Use human names "John" instead of "Candidate 1".
- Test against hardcoded values: expect(json['name']).to eq 'John' instead of expect(json['name']).to eq candiate.name.
- Write code example.
- Mock every external call to the internet (HTTP, gPRPC)
Don'ts
- Don’t write “should” in spec messages:
- Wrong: it “should return the calculation result”
- Right: it “returns the calculation result”
- In general, Don't use faker (fake values generating library), use hardcoded values.
- They could introduce flaky tests.
- Having hardcoded values helps create a story in the test suite.
- Exception: Running tests with a series of random values to find bugs (we don't remember the name of this testing technique, if someones remembers put it here please).
- Don't test more than one thing per test in unit tests. Integration tests are allowed to test more than one thing because they are expensive to run.