Skip to content

Instantly share code, notes, and snippets.

@jitendravyas
Forked from mrmrs/front-end-testing.md
Created April 7, 2016 21:41
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jitendravyas/813c9edb09305ea51673aedb33577932 to your computer and use it in GitHub Desktop.
Save jitendravyas/813c9edb09305ea51673aedb33577932 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.

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