Subscribe

By: Ian McNally

Print this Page

May 20th, 2016

14 Tips for Better Front End Testing

Languages, Tools, Frameworks

In the last few years, test driven development on front end code has proliferated, thanks to javascript frameworks that make it easier. Here are a few tips I picked up along the way to make testing faster, easier and more comprehensive.

 

1. Test output (how the DOM changes), not what happens 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.

"We fear change" from Wayne's World

 

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 "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 flips her hair because she's self sufficient

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 montage

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.

Cat staring into the distance feeling alone

7. Turn on source maps, if applicable

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

"What year is it?" asks the guy from Jumanji

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

The key to TDD is speed, speed, speed.

A headless ghost turns a pole

9. Allow for in-browser debugging

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

A web browser from a video game

10. Have consistent names for your test blocks

File names, methods, modules

Belle swings on her library's ladder

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

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

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.

Daenerys says "I shall show you 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.

Man plugins in cord and smiles foolishly

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 Knope yells "No"

 

Want to get started on a new front end project quickly, with a great testing setup already in place?Check out Stride's 2016 web boilerplate project.

 

If you found this helpful and would like to learn more about Stride. Click the link below to contact us!

Let's up your game.

About Ian McNally

Ian is a lead consultant at Stride.

  • Connect with Ian McNally

Related Posts