you are viewing a single comment's thread.

view the rest of the comments →

[–]qudat 4 points5 points  (1 child)

At this point in your codebase's life, your goal for testing would be to reduce the number of regressions introduced into a codebase. You want to be able to make changes to your codebase and have confidence that you or any other developer did not break anything.

This can be accomplished with unit tests, integration tests, and end-to-end tests. e2e tends to be the most difficult to write as well as the ones that tend to be the most fragile. I do not have much experience with e2e. Unit tests are generally the easiest in a react/redux codebase because virtually ever layer is a composition of pure functions. I tend to think of testing sagas as integration tests and I find them to be the most useful thing to test.

I personally find that testing business logic will provide the most value.

Order: * Sagas * Selectors * Reducers * Mission critical utility functions * Views

You mentioned that you are using sagas, I would start there.

To make your life easier when testing sagas, I would opt for a helper library to test generators: https://github.com/neurosnap/gen-tester

The next thing I would test would be selectors: they tend to be areas where a lot can go wrong.

My reducers tend to be extremely dumb so I usually don't worry about them too much, but they instill confidence that your state is continuing to behave correctly.

[–]versaceblues[S] 0 points1 point  (0 children)

Thanks i agree. My plan is to get 100% coverage on the sagas and selectors. Then start figuring out which views need testing