It doesn’t really matter how you do your tests, as long as you write enough tests that make you feel confident that you can deploy your version to production.
When coming up with a testing plan, we should avoid a culture that pressures developers to write a test for every file.
Developers need to feel empowered to make smart testing decisions, without worrying that they’re “not testing enough.”
Coverage reports can help with this by providing a sanity check that you’re achieving good coverage, even if the tests are consolidated that the integration level.
Unit Test
- Unit test verifies one piece of code in isolation.
- Code that is unit-testable is code has little dependencies on other modules, and does no I/O (no files, databases, also no Ajax calls, local-storage, DOM access and manipulation. Anything that touches a browser API is I/O).
end-2-end test
- End-to-end tests interact with your site like a user: loading pages, filling out forms, clicking buttons.
- They are executed against a system that has all required components to be deployed and running
- They are generally slower to write and run, but closely match the real user experience.
Integration Test
- Integration test validates how multiple units of your application work together but are more lightweight than E2E tests.
- They may have utilities to facilitate integration testing. For example, emulation of common browser APIs or robust mocking tools can stub out external API calls