5.9 KiB
Contributing: Tests
Testing is an opinionated topic. Here is a rough overview of our testing philosiphy. See something you want to discuss or think should be changed? Open a PR and let's discuss.
You're an engineer. You know how to write code, and writing tests isn't all that different. But do you know why we write tests? Do you know when to write one, or what kind of test to write? How do you know if a test is a "good" test? This document's goal is to give you the tools you need to make those determinations.
Okay. So why do we write tests? To increase our... 🥁:
CONFIDENCE
I want to be confident that the code I'm writing... won't break the app that I have running in production. So whatever I do, I want to make sure that the kinds of tests I write bring me the most confidence possible and I need to be cognizant of the trade-offs I'm making when testing. - Kent C. Dodds
Kinds of Tests
Test's buy us confidence, but not all tests are created equal. Each kind of test has a different cost to write and maintain. An expensive test is worth it if it gives us confidance that a payment is processed, but it may not be the best choice for asserting an element's border color.
| Test Type | Example | Speed | Cost |
|---|---|---|---|
| Static | addNumbers(1, '2') was called with a string, int was expected. |
🚀 Instant | 💸 |
| Unit | addNumbers(1, 2) returns expected result 3 |
✈️ Fast | 💸💸 |
| Integration | Clicking "Sign In", navigates to the dashboard (mocked network requests) | 🏃 Okay | 💸💸💸 |
| End-to-end | Clicking "Sign In", navigates to the dashboard (no mocks) | 🐢 Slow | 💸💸💸💸 |
Static Code Analysis
Modern tooling gives us this "for free". It can catch invalid regular expressions, unused variables, and guarantee we're calling methods/functions with the expected paramater types.
Example Tooling:
- ESLint
- TypeScript or Flow
Where it falls short: Can't test business logic.
Unit Tests
...
When should we unit test?
Follow the top level exports. Anything that is exposed as public API should have unit tests. These are th
When should we avoid unit tests?
You're testing implementation details if:
- Your test does something that the consumer of your code would never do.
- IE. Using a private function
- A refactor can break your tests
Where it falls short: That you're calling a dependency appropriately.
Integration Tests
Integration tests take things one step further. You
Where it falls short: That you're passing the right data to your backend.
End-to-End Tests
These are the most expensive tests to write and maintain. Largely because, when they fail, they have the largest number of potential points of failure. So why do we write them? Because they also buy us the most confidance.
We should reserve end-to-end tests for mission critical features. A good example is testing user authentication. If a user can't sign in to your application, it's an emergency. Having a high degree of confidance that users can always authenticate is very valuable.
Where it falls short:
When should we test?
Mission critical features and functionality, or to cover a large breadth of
functionality until unit tests catch up. Unsure if we should have a test for
feature X or scenario Y? Open an issue and let's discuss.
Further Reading
Okay, so hopefully you have more confidance in your understanding of why we test, and the trade-offs we weigh when determining what kind of test should be written. For the how, check out some of the links below, or read some of the existing tests in this repository.
General
- Assert(js) Conf 2018 Talks
- Write tests. Not too many. Mostly integration. - Kent C. Dodds
- I see your point, but… - Gleb Bahmutov
- Static vs Unit vs Integration vs E2E Testing - Kent C. Dodds (Blog)
End-to-end Testing w/ Cypress
- Getting Started
- Be sure to check out
Getting StartedandCore Concepts
- Be sure to check out
- Best Practices
- Example Recipes