Skip to content

Instantly share code, notes, and snippets.

@sapegin
Created March 2, 2018 08:23
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sapegin/daa2af49e0c606007e5c7f29f8b41986 to your computer and use it in GitHub Desktop.
Save sapegin/daa2af49e0c606007e5c7f29f8b41986 to your computer and use it in GitHub Desktop.

Testing guidelines

TODO: find examples

What to test

React — integration tests

Mount your app (page) root component and test happy path and main error cases with Enzyme.

This way you can validate that the app is actually working and doing what you want.

Redux — duck tests

Test all Redux actions by creating a store and dispatching actions on this store.

This way you’ll test the whole Redux chain: action creators, reducers and selectors.

The state update logic in reducers may be complex and having good coverage is essential. Though unit-testing reducers separately won’t bring much value over duck-testing the whole Redux chain, but will slow down changes.

Algorithms — unit tests

Test static functions that contain tricky logic.

This way you can be sure that all calculations and logic are correct, and edge cases are properly handled.

This will also make code more independent and isolated. You won’t be tempted to keep such functions inside React components, because it’ll make testing harder.

Rationale

We want to be sure that any changes, especially done by other teams, won’t break our code. We also want to be able to refactor our code safely.

So we should spend most of our testing efforts on tests that will give us the most confidence, witch the least maintenance time.

Too many low-level (unit) tests make code changes harder and slower without giving you much confidence. They are tightly coupled to the implementation: any code changes will require tests to be updated, just moving code around will break many tests. Unit tests can’t guarantee that the app is actually working, even with high code coverage.

High-level (integration) tests may be harder to write, but they don’t depend on implementation details and won’t break that often during refactoring. They will give us confidence but won’t slow slow down code changes.

Resources

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment