14 tips for better front end testing

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

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

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 "Let's do this."

Liz Lemon says "Let's do this."

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

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

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

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

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

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

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

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

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

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

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

Leslie NO-OPE