GreenOnion, The New UI Testing Tool

Don’t cry. We’ve all been there too. Regression issues in the presentation layer make the entire team go crazy. Why can’t we have a methodical way of testing the UI to ensure once designs are styled as views, they stay the way they were created?

The first release of GreenOnion is an attempt at just that. It moves from testing code to testing the visual interfaces that designers have envisioned and end-users will interact with. Developed after reading Jeff Kreeftmeijer’s post on creating image diffs, GreenOnion brings together both OilyPNG and Capybara to test the UI.

RSpec, MiniTest, Test::Unit all allow devs to create solid code using BDD/TDD, but there has yet to be a good way to make sure bugs are not introduced in HTML and CSS. Sure, we have Watir and Capybara (a dependency of GreenOnion), but these tools are more focused on the functionality of views rather than how they actually look. GreenOnion captures and compares what the user would actually see. There will never be a sure-fire way to fully automate testing something so subjective as visual aesthetic, but GreenOnion should help the designer or developer by highlighting where things might be going wrong.

The GreenOnion workflow

  • Run skin method for the 1st time on a URL (best case would be if the styling of the page was correct)
  • Save skin
  • Run skin method for the 2nd time on a URL
  • Compare 1st skin to the 2nd (fresh) skin

Percent of change

GreenOnion.skin_percentage(url, threshold [optional])

The primary feature of GreenOnion is seeing how much (if at all) a view has changed from one instance to the next, and being alerted when a view has surpassed into an unacceptable threshold.

What do we mean by threshold?

The threshold is the percentage of pixels that are allowed to change from one iteration of a view to the next. This will give the view tolerance of change, and if that tolerance has been surpassed, then the test will alert the developer.

Visual change


Once you are aware of a issue in the UI, you can also check out where the offending issue may have taken place. You should open your “skins” directory, and check out the files with “_diff.png” at the end of the filename. The pixels will be highlighted and will have the same effect as the Photoshop “difference” filter.


We hope that this is just the beginning of more robust testing in the UI. Here are some areas that we will focus on in the future:

  • Screenshots can either be viewed as a visual diff, or overlayed newest over oldest and viewed as an onion-skin with sliding transparency.
  • Allow for flexibility in picking browsers
  • More robust skinner generator
  • Should allow for testing using fixtures/factories
  • Flexibility in skin filenaming
  • Test with UI events