Hacker News Reader

Comment by MatthewPhillips | Hacker News Reader

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?

View on HN

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.)

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)

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.

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

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.

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

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.

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

Reply on news.ycombinator.com