Why it's crucial to test your frontend code

This article first appeared in issue 233 of .net magazine – the world's best-selling magazine for web designers and developers.

Testing isn’t a word I hear frequently in frontend development circles. This isn’t to say they don’t test, but it doesn’t appear to be a mainstream practice yet.

The frontend development landscape is shifting, as is the necessary skillset. So I’ve been considering methods and tools for automating CSS testing.

I see four particularly useful types of CSS tests:

  • Validation: syntax errors and potential compatibility errors
  • Rendering: how the CSS is rendered by different browser engines
  • Performance: speed and efficiency
  • Regression: ensuring changes didn’t introduce any problems

Have you ever:

  • Found a typing error in CSS?
  • Clicked through a site to verify that it looked the way it was supposed to?
  • Had a demo site working perfectly only to discover a bug introduced during implementation in a production environment?
  • Refactored/changed CSS ensuring you didn’t break anything along the way?
  • Analysed and optimised CSS performance?

In the absence of an automated test suite to find problems, I’d like to introduce some tools and automation processes related to these four areas.


While CSS validation can be contentious, I like CSS Lint because it checks for syntax errors and flags potential maintainability and performance problems.

CSS Lint has been integrated with a number of IDEs, can be run from the command line on a directory, and integrates with a variety of build systems and automation scripts including Ant, Node, Rhino, Grunt, and Rake. The rules as well as integration options are documented in the CSS Lint wiki.


Most CSS testing occurs while ensuring a site looks like it is supposed to across varying browsers. Typically this is done manually – inspecting a site in browsers to verify its appearance.

Style guides can be great tools to assist in the process. Styleguides vary greatly, but typically document and show markup patterns for all reusable components in a site. There are a number of tools to help automate style guide creation from existing code. I highly recommend KSS and Kalei.


CSS is not typically the largest offender in slowing down site performance but it does have an impact. Dust-me selectors is one of several tools that offer an analysis of unused selectors. They can also be used in combination with a Rake file to automate the physical removal of the unused styles.


Two projects that appear particularly promising in regards to automating regression tests are Cactus and Needle. Cactus is a proof of concept that works with Rails and facilitates testing based on computed CSS rather than screenshots. Needle enables automated regression testing by generating and comparing screenshots of a portion of a website checking the current rendering with the original screenshot.


This is just scratching the surface, but I hope I’ve sparked thoughts on integrating and automating CSS testing into site development workflow.

Discover 20 inspirational examples of CSS over at Creative Bloq.

Thank you for reading 5 articles this month* Join now for unlimited access

Enjoy your first month for just £1 / $1 / €1

*Read 5 free articles per month without a subscription

Join now for unlimited access

Try first month for just £1 / $1 / €1

The Creative Bloq team is made up of a group of design fans, and has changed and evolved since Creative Bloq began back in 2012. The current website team consists of seven full-time members of staff: Editor Georgia Coggan, Deputy Editor Rosie Hilder, Deals Editor Beren Neale, Senior News Editor Daniel Piper, Digital Arts and Design Editor Ian Dean, Tech Reviews Editor Erlingur Einarsson and Ecommerce Writer Abi Le Guilcher, as well as a roster of freelancers from around the world. The 3D World and ImagineFX magazine teams also pitch in, ensuring that content from 3D World and ImagineFX is represented on Creative Bloq.