Remember, it's all about getting a good return on your investment where "return" is "confidence" and "investment" is "time." - Kent C. Dodds
People love debating what percentage of which type of tests to write, but it's a distraction. Nearly zero teams write expressive tests that establish clear boundaries, run quickly & reliably, and only fail for useful reasons. Focus on that instead. - Justin Searls
Write tests. Not too many. Mostly integration. - Guillermo Rauch
- Structure tests with Arrange, Act, Assert.
- Write the easy tests first to hedge against testing fatigue.
- Test the happy path first and then layer in specific scenario tests.
- Don’t mock what you don’t own.
- Don’t test implementation details.
- Name the test as if you were describing the scenario to a non-programmer.
- When I read tests for business logic, I want the intent of the test to be obvious on first glimpse. – Look out for tests that are much slower than similar tests in the suite.
- Methodology
- Stick to the pyramid shape to come up with a healthy, fast and maintainable test suite: Write lots of small and fast unit tests. Write some more coarse-grained tests and very few high-level tests that test your application from end to end.
- Static > Unit > Integration > E2E
- What to test
- When writing a test, try to break the method's code down and identify specific pieces that can be asserted against. For example,
- The returned output of a method based on the input.
- Whether a user was authenticated or logged out.
- Whether any exceptions were thrown.
- Whether any rows in the database changed.
- Whether any jobs were added to the queue.
- Whether any events were dispatched.
- Whether any mail or notifications were sent (or queued).
- Whether any external HTTP calls were made.
- When writing a test, try to break the method's code down and identify specific pieces that can be asserted against. For example,
- Naming Tests
- Tools
- Fakes
- Mocks
- Spies
- Stubs