Testing React components is really confusing at first. It can be difficult to figure out exactly what to test, especially after the "unit test pure functions!" dogma of Testing Week.
Stateless React components are effectively pure functions, so it seems like you should unit test them, but most of the time this ends up with pointlessly testing markup.
const Button = ({ children }) => <button>{children}</button>
is essentially just some HTML, so it seems a bit of a waste of effort to unit test it just because it happens to be a function.
It would be better to cover this component as part of an integration test that actually checks some functionality.
Workshop
The idea is to follow up the Dynamic Data workshop with this one, writing tests for the components they just built. We'll make sure everyone can pull a clean solution if they didn't manage to finish the previous workshop.
Introduce Jest (as most won't have used it before)
Rendering to a fake DOM in Node (Jest has JSDom built in)
Mocking a fetch request so we're testing just the component, not any external dependencies
Enzyme
In my opinion Enzyme has a huge bloated API that isn't well-suited to learning to test. It encourages you to write bad tests because you can pretty much do anything with it, and the docs aren't great so it takes forever to figure out how to do what you want to do.
Snapshots
Over the last 9 months we've become less and less enamoured with snapshot testing components at Ticketmaster. They end up effectively serving the same purpose as reviewing a diff in a PR.
Snapshots are useful for testing generated output and making sure it doesn't change when you refactor (e.g. we use them for testing date/currency formatting), but not HTML/CSS output
Testing React components is really confusing at first. It can be difficult to figure out exactly what to test, especially after the "unit test pure functions!" dogma of Testing Week.
Stateless React components are effectively pure functions, so it seems like you should unit test them, but most of the time this ends up with pointlessly testing markup.
is essentially just some HTML, so it seems a bit of a waste of effort to unit test it just because it happens to be a function.
It would be better to cover this component as part of an integration test that actually checks some functionality.
Workshop
The idea is to follow up the Dynamic Data workshop with this one, writing tests for the components they just built. We'll make sure everyone can pull a clean solution if they didn't manage to finish the previous workshop.
Enzyme
In my opinion Enzyme has a huge bloated API that isn't well-suited to learning to test. It encourages you to write bad tests because you can pretty much do anything with it, and the docs aren't great so it takes forever to figure out how to do what you want to do.
Snapshots
Over the last 9 months we've become less and less enamoured with snapshot testing components at Ticketmaster. They end up effectively serving the same purpose as reviewing a diff in a PR.
Snapshots are useful for testing generated output and making sure it doesn't change when you refactor (e.g. we use them for testing date/currency formatting), but not HTML/CSS output