How does unit testing work for front-end React-based applications in 2017?
Components can be tested with snapshot testing. Tools like Jest (often combined with Enzyme) that offer this functionality take a ‘snapshot’ of what your component renders — everything from divs, attributes, classNames, props, and state — and saves it to a file, kind of like this:
On subsequent test runs, Jest makes a new snapshot to compare with the old and breaks if the two don’t match, preventing any unintended changes to the rendering of your component. It’s not perfect as you can’t really do true test-driven-development where you make a failing test first then fix it, so you just have to trust that your initial snapshot is correct, but it’s real quick and easy:
Selectors are pretty handy stuff. They untangle the mess that Redux state often ends up turning into and they allow you to abstract gnarly logic out from reducers so they stay clean and simple. Using the common createSelector function, it takes in some arguments and spits out some other function that takes in state and returns what you want selected from said state:
I guess I could mock the whole state, pass it through, and then check that it returns what I want it to, but that’s a lot of work.
All I really want to do is check the last function parameter, the function that actually performs the custom logic, and it just so happens that the object createSelector returns has a property, resultFunc, that returns the last passed-in function. Using this, we can test selectors like this:
Epics are the core primitive of redux-observables, a RxJS-based middleware for Redux. I highly recommend giving observables and reactive programming a try because it makes dealing with asynchronous and/or event-based problems like user interactions, animations and timers, websockets, and AJAX calls a breeze.
Epics are functions that receive and output a stream of actions. The simplest way to test epics, in my experience, has been to just test the bare minimum of what an epic is supposed to do — actions in, actions out. Invoke your epic with an action, then test that the output action is what you expected.
Let’s say you got an epic that handles the flow for successful logins. Upon a successful login, you want to dispatch multiple actions: one to change routes, one to change authenticated state, and one to indicate the form submission has been completed:
In our testing, what we want to do is feed in an action of type LOGIN_TYPES.SUCCESS, and test that the output returns the three dispatched actions:
If you want to learn more about this method, here’s a good article from Kevin Salter about testing epics:
Testing doesn’t have to be a drag. It’s 2017 and we have the technology. Go write some tests and have fun.
I’m a Software Developer who writes about the things I learn about.
Check out my other articles at: