3 ms·
> 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
by nexfitter 9y ago
> 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 https://imgur.com/a/gqgcS
- reledi 9y agoI 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 https://twitter.com/dan_abramov/status/824310320399319040
- nexfitter 9y agothat is a really cool technique, thanks for the link!