Skip to content

Instantly share code, notes, and snippets.

@mrmrs
Last active April 7, 2016 21:41
Show Gist options
  • Star 7 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save mrmrs/721e44e6f972303eb376 to your computer and use it in GitHub Desktop.
Save mrmrs/721e44e6f972303eb376 to your computer and use it in GitHub Desktop.
Thoughts on front-end testing

UI development as a first-class citizen

The single hardest part of front-end development at scale is making changes to code and understanding all of the visual and behavioral effects that will occur as a result.

When you build a component, tests should be written that expose each state a component can be in. This test should generate a static html file and a corresponding image for every discrete state a component can be in.

What is a component? Everything is a component. A link is a component. A page is a component. Components can be composed of other components.

If a component can be in more than 1 state - a test that generates all of these states should be written before visual ui implementation is started on. This allows the front-end developer to see all states simultaneously. This has an enormous effect on both the development velocity of new components but also the ability to refactor or modify existing components.

For example: If a user can click on a button and reveal new content within the interface - then there should be a test that generates this state. If different accounts render different text to within a component this should be reflected in a test for the component.

When a component has fully undergone manual visual testing and passed - this would allow you to add it to a canonical set of images and html files. These images and html files can be diffed against new renderings of a component during or after the process of refactoring or making modifications to the component. This would help illustrate anything that could be broken after making code changes by returning a list of html files and images that represent visually broken interfaces to speed up the ability to fix UI without rigorous manual (and time consuming) testing. This will also help new members of a dev team get a comprehensive overview for all the states an interface can be in. This feature is also immensely beneficial for designers who are trying to change an interface and want to audit what is already existing for context.

We can live in this world. The technology exists. We just need to be intentional.

It's time to treat front-end development as a first class citizen.

@SlexAxton
Copy link

Per component, mixed states, as well as a few common integrations - all visual diffed after every commit at 4 breakpoints (where it makes sense). Most of this is just node-huxley, saucelabs - declarative states made possible by https://github.com/SlexAxton/rework-pseudo-classes

http://slex.me/image/0T0q3X40043Q/Screen%20Shot%202015-06-01%20at%207.40.36%20PM.png

http://slex.me/image/14243R3X101s/Screen%20Shot%202015-06-01%20at%207.45.55%20PM.png

@johno
Copy link

johno commented Apr 4, 2016

This rings so true for me.

As mentioned previously, this really sounds like an argument for a living styleguide. You can also tie in how the logic/state functionality of a component is often rigorously tested (like a React/Ember component). It's extremely helpful in diagnosing regressions early in the development cycle. So, it makes to take this further and automate the testing of the visual aspects in components, too. This ensures changes are targeted towards the desired components and won't propagate throughout the app.

Also, somewhat related: https://www.youtube.com/watch?v=ItyUjVWl4q8

Some spelling and grammar

corresponding image file for every discreet state a component can be in

discrete

written before visual ui implmentation

UI implementation

and to treat front-end like a first class citizen

treat the front-end

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment