3 ms·

That's why most people say to separate the connected component (that gets few props) wrapping the unconnected one (that gets a lot of props). You usually test t

That's why most people say to separate the connected component (that gets few props) wrapping the unconnected one (that gets a lot of props). You usually test the unconnected. If you want to test the connected component, it's still good to separate them as you won't test the same things (correct props are passed down, rather than UI renders)

alangpierce 8y ago
Makes sense to test the inner unconnected component when you want a focused unit test on the component. FWIW, I greatly prefer integration tests (using JSDOM and enzyme) when working with React/Redux, since they're often easier to write than unit tests and give me much more confidence in the software, and they don't have the speed or reliability downsides that some people talk about with integration tests. Unit tests certainly have their place, though. As one (admittedly extreme) example, a while back I hit an issue where a refactor caused a very simple crash: just load the app, click a particular button, and it immediately crashes. All relevant components, actions, stores etc had extensive unit tests, but there was no test to make sure that the component dispatched an action that was compatible with what the store wants. I wrote an integration test for it, "load the app and click this button, and assert the intended effect", and it ended up being about 5 lines. It exercised the same code paths as the hundreds of lines of unit tests, and gives me much more confidence in the overall correctness of the system.
- williamdclt 8y ago
  Yeah I've had the same kind of problem: 100% test coverage by unit testing but I still had crashes because I wasn't testing integration. I'd like to move to a page-based testing, where I mount the entire page and interact with it, asserting what's going on visually and in the store

3 ms·

That's why most people say to separate the connected component (that gets few props) wrapping the unconnected one (that gets a lot of props). You usually test t

by williamdclt 8y ago

alangpierce 8y ago
Makes sense to test the inner unconnected component when you want a focused unit test on the component. FWIW, I greatly prefer integration tests (using JSDOM and enzyme) when working with React/Redux, since they're often easier to write than unit tests and give me much more confidence in the software, and they don't have the speed or reliability downsides that some people talk about with integration tests. Unit tests certainly have their place, though. As one (admittedly extreme) example, a while back I hit an issue where a refactor caused a very simple crash: just load the app, click a particular button, and it immediately crashes. All relevant components, actions, stores etc had extensive unit tests, but there was no test to make sure that the component dispatched an action that was compatible with what the store wants. I wrote an integration test for it, "load the app and click this button, and assert the intended effect", and it ended up being about 5 lines. It exercised the same code paths as the hundreds of lines of unit tests, and gives me much more confidence in the overall correctness of the system.
- williamdclt 8y ago
  Yeah I've had the same kind of problem: 100% test coverage by unit testing but I still had crashes because I wasn't testing integration. I'd like to move to a page-based testing, where I mount the entire page and interact with it, asserting what's going on visually and in the store