## Pick one
- Fast but not Comprehensive
- Comprehensive but slow
## Unit testing
- Great to test and document business logic
- Very fast
- Detached from the user journey
- Not good for documenting platform behaviour
## Cypress
- Great for documenting user behaviour
- All the browser API available (no need to mock browser functionality)
- Not brittle compared to selenium, puppeteer (in build retry)
- Slow (spin up only can take 1+ minutes)
## React testing library
- Can render to JSDOM, an emulation of a subset of browser dom
- Very fast (even rendering a whole page is < 100ms)
- Can test both small components or the whole page
- Can document user and platform behaviour
- Has cypress bindings
- No need to run the app to run the tests
- Needs mocking for standard browser functionality (ie: i18n)
## Testing burger
- A few of e2e tests
- Lots of integration tests
- A few unit tests for key business logic
## Why more integration tests?
- Not much more expensive than unit tests
- Less coupling (fails mostly if functionality changes)
- Documentation (mimic user behaviour)
- Quick even if comprehensive
- Many advantages of e2e testing without the cost
## Could we remove e2e test altogether?
- "Smoke test" to check that the platform is running
- Testing integration with our graphql (not just a mock)
- Tests idp-provided cookies
- Generate har files for load testing
## How this translates for new features
- E2E for golden path (ie: a few tests per epic)
- Integration tests coverage for most of the code we ship
- Unit tests as necessary
## What about existing code
- Clean up E2E tests and keep the valuable ones
- When working on existing code, expecially for big refactorings, add tests as see fit
## Next steps
- Unit tests pre-push, pipeline
- Integration tests pre-push, pipeline
- E2E testing post-deploy
- Code coverage report