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