4 ms·

I'm not a React dev, but both approaches seem like they would make testing harder. Prop drilling must be the most testable approach. Am I wrong?

meesles 8y ago
You're right, but testing the whole page's component functionality in large frontend apps isn't super common, either. In these cases, you would test the lower-level components and then not necessarily test their functionality for the whole page. The costs of deep prop trees 1) kills many performance benefits offered by a good react/redux setup 2) makes it hard to build off of the state (much like a monolithic codebase) because it can be harder to find if something is already there or not.
- antjanus 8y ago
  I'm a non-React dev but I wrote modern apps with Angular (and have written React). I think the best testable approach really is: 1. unit testing on the smallest bits (Redux actions/reducers make unit testing them SUPER easy) 2. do e2e with something like Cypress. Anything in between can be helpful but I found it can be too tedious, or difficult to do and ultimately, unit/e2e catches most things
  - dceddia 8y ago
    I think this is a solid approach. I like to add snapshot testing for individual components too. The slowest tests to write for me are always the ones that involve some kind of async stuff.
alangpierce 8y ago
It definitely makes testing a bit different. The downside to prop drilling is that you get components with lots of props, and it can be tedious to figure out how to render a component at all if you need to pass in 20 props for all of its transitive dependencies. The upside is that you have a clear list of the 20 needed props, and once you've figured them out, your component will work. With Redux and Context, you might have test setup code always populate the store with reasonable defaults for the 20 different data dependencies. Then, a typical test might update a few things in the store with test-specific values, render <Nav /> without the need to specify any props, and then perform interactions, inspect the results, etc. There's more going on behind the scenes, but it's also easier to get started because you don't need to figure out 20 props. (There are many, many ways to think about testing here, though, and this is just one approach.)
- williamdclt 8y ago
  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
deleted 8y ago
[deleted]
AlexCoventry 8y ago
redux-saga-test-plan has a few warts, but it's made testing HOC interactions fairly straightforward for me.

meesles 8y ago

You're right, but testing the whole page's component functionality in large frontend apps isn't super common, either. In these cases, you would test the lower-level components and then not necessarily test their functionality for the whole page. The costs of deep prop trees 1) kills many performance benefits offered by a good react/redux setup 2) makes it hard to build off of the state (much like a monolithic codebase) because it can be harder to find if something is already there or not.

antjanus 8y ago
I'm a non-React dev but I wrote modern apps with Angular (and have written React). I think the best testable approach really is: 1. unit testing on the smallest bits (Redux actions/reducers make unit testing them SUPER easy) 2. do e2e with something like Cypress. Anything in between can be helpful but I found it can be too tedious, or difficult to do and ultimately, unit/e2e catches most things
- dceddia 8y ago
  I think this is a solid approach. I like to add snapshot testing for individual components too. The slowest tests to write for me are always the ones that involve some kind of async stuff.

alangpierce 8y ago

It definitely makes testing a bit different. The downside to prop drilling is that you get components with lots of props, and it can be tedious to figure out how to render a component at all if you need to pass in 20 props for all of its transitive dependencies. The upside is that you have a clear list of the 20 needed props, and once you've figured them out, your component will work. With Redux and Context, you might have test setup code always populate the store with reasonable defaults for the 20 different data dependencies. Then, a typical test might update a few things in the store with test-specific values, render <Nav /> without the need to specify any props, and then perform interactions, inspect the results, etc. There's more going on behind the scenes, but it's also easier to get started because you don't need to figure out 20 props. (There are many, many ways to think about testing here, though, and this is just one approach.)

williamdclt 8y ago
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

deleted 8y ago

[deleted]

AlexCoventry 8y ago

redux-saga-test-plan has a few warts, but it's made testing HOC interactions fairly straightforward for me.