You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Testing has become a real pain point. There are two related issues here:
tape and karma-tape just aren’t very usable. The most acute pain comes from the lack of file/line information in test failures; a close second is the basically unreadable error output.
I’ve made some mistakes in the way I have structured the tests. Specifically:
The reducer tests use the reducerTest helper function, which takes a before-state, an action, and an expected after-state. This however does not match the way one naturally thinks about testing reducers, namely: start with this state; apply this action; then make specific assertions about the resulting state (rather than just saying “this is what the resulting state should be”).
Reusable test helpers, particularly for creating test data, are unintuitive and not well-structured. We should have factory modules for each category of object we’d like to create: e.g., one for objects that the Firebase SDK would give us; one for objects that the GitHub API would give us; etc. We should use something like rosie to make factories simple to build and easy to extend.
Test code should not do direct manipulation on Redux state data structures. Redux state used in tests should always be generated by running a series of actions through the reducers. We should have a helper module to make this boilerplate-free.
The text was updated successfully, but these errors were encountered:
Testing has become a real pain point. There are two related issues here:
tape
andkarma-tape
just aren’t very usable. The most acute pain comes from the lack of file/line information in test failures; a close second is the basically unreadable error output.reducerTest
helper function, which takes a before-state, an action, and an expected after-state. This however does not match the way one naturally thinks about testing reducers, namely: start with this state; apply this action; then make specific assertions about the resulting state (rather than just saying “this is what the resulting state should be”).rosie
to make factories simple to build and easy to extend.The text was updated successfully, but these errors were encountered: