- Test a single Component, Service, Pipe etc.
- Test a single specific behaviour in a controlled environment
- Mock everything you need to test this functionality
- Use code coverage analysis to make sure everything is covered
- (Usually) Improves code structure and quality
- Test edge cases on the most detailed level
- Know if a change breaks a specific behaviour
- Does not test if the whole application or a process works in real life
- Test complete processes “End 2 End”
- Test in real environments with the whole application
- Test real live situations
- Know if most important features work with the complete application
- Focussed on the overall functionality and not the specific code structure
- Does not test Edge cases
- Does not necessarily improve code quality
- Stick to the happy path. This lets us know when something breaks for the majority use case. Unit tests should catch the nitty gritty.
- Only test what you need to. With unit tests, write tests that assert your component's public interface, and treat its internals as a black box. A single test case would assert that some input (user interaction or change of props) provided to the component results in the expected output (render result or emitted custom events).
- For example, for a Counter component which increments a display counter by 1 each time a button is clicked, its test case would simulate the click and assert that the rendered output has increased by 1. The test doesn't care about how the Counter increments the value, it only cares about the input and the output.
- Write regression tests. If a bug is fixed, write a test for the related code so it doesn't break again.
- Create a fake data generator that uses Faker (https://www.npmjs.com/package/faker) for random data for each test
- Build the test to fail first, then success. This ensures the test truely passes.
Provide specific failure messages
- Bad:
Test timed out - Good:
Test timed out after 60 seconds waiting for home hero banner to load