[nexfitter]

> Have I just made something public in order to test it? > > If yes, consider instead writing higher level tests that each each test more of the code.

This is one that I struggle with in JS with React.js components. If you have a little helper component in a file that isn't exported but used in the same file by a component that is exported, it is sometimes difficult to test that non-exported component. Because of how enzyme shallow rendering works you don't get the full tree so that component, if sufficiently nested, might not ever be touched. This forces me to export the component just to test it.

example: https://imgur.com/a/gqgcS

[reledi]

I run into the same problem with React and it bugs me from a testing standpoint.

Extracting code from a big component to helper functions and extracting those functions from the component can lead to cleaner code, and it makes it much easier to test the behaviour of the helpers directly than having to render the component with enzyme.

A good example of this is moving state changes to pure functions [1] which makes them much easier to test, but you'll need to export those functions to test them.

1: https://twitter.com/dan_abramov/status/824310320399319040

[nexfitter]

that is a really cool technique, thanks for the link!