Ian McNally

14 tips for better front end testing

May 20, 2016

Today Stride published a set of tips I put together for testing your front end code. I had some fun with it, by turning it into a Buzzfeed-style listicle.

Here it is in syndication:

1. Test output (how the DOM changes), not what happen behind the scenes (implementation)

Think about the user’s perspective and how they would interact with the component(s). Testing output allows you to change implementation, without affecting output. That means tests only break when there’s an actual functionality change.

 Garth fears change

2. Make reusable components that can be tested in isolation

They’re easier to test and makes tracking down changes faster.

 Reduce, reuse, recycle

3. Cut down on the amount of DOM rendering in tests

When setting up your tests, prefer `before` not `beforeEach` to cut down on repeat renderings. It can slow things down considerably.

 Liz Lemon says

4. Isolate mutations to tests contexts

Relying on other cases mutating state or DOM leads to brittle tests that are hard to refactor or reason about. Test blocks contexts should be self-sufficient. Resist the urge to share data.

 Beyonce's Miss Independent

5. Be explicit and don’t abstract too much setup or repetition

By writing out and repeating steps, it’s easier to scan the code while under stress.

 The Beatles, repeating

6. Choose a tool that allows you to isolate cases for a faster feedback cycle.

Have and use the ability to isolate a test or tests, without running them all. It’s easier to focus and faster to find the change.

 Forever alone cat

7. Turn on source maps, if applicable

Get pointed to the source code quicker, if you’re using a compiler.

 What year is it? Also, RIP Robin Williams

8. Use a headless browser and rerun tests on file change

The key to TDD is speed, speed, speed.

 A headless ghost spins a pole

9. Allow for in-browser debugging

For the times you just need that Chrome dev tools. (And maybe Firefox or Safari)

 A really strange web browser

10. Have consistent names for your test blocks

File names, methods, modules

 Belle swings across her library on a ladder

11. Make your `describe`s, `context`s, `it`s human readable

Mad lib style: [Module name], when [state], (and), it [behavior]

 It's a mad, mad, mad lib world

12. Include polyfills if testing on different browsers

Browsers behave differently, especially older versions of PhantomJS versus something like Chrome. A polyfill like es5-shim will get you to parity.

 Show browser variations no mercy

13. Use a pluggable expectation system for more meaningful assertions

For example, chai-jsx (or expect-jsx or jasmine-expect-jsx), if you’re using React, allows you to assert with JSX on a component. Same goes for libraries like immutable, sinon, bluebird.

 Plug it in, plug it in

14. Fail the build on console.error

A third party developer is politely telling you there’s been a horrible problem, without crashing your app (isn’t that all you can ask for in a client-side app?). This happens with prop type validation errors in React.

 Leslie NO-OPE

Ian McNally

Hey, I'm Ian. I build websites and write about what I learn as I go. Follow me on Twitter.