Warhol

Today is the day Warhol finally opens its doors to the public 🎉!

Warhol is a set of tools and services that turn pattern libraries into tests for your web project's design. Warhol analyzes the styles on example components in your pattern library and then compares them to your production web page. Unlike other design testing tools, Warhol does not rely on screenshots and pixel-by-pixel comparisons. Instead, it performs its tests on the HTML and CSS used by both the pattern library and the production web page. This makes Warhol fast enough to run tests right inside your browser and provides the flexibility to ensure that an example component with example content and a real-life production component do in fact, for all intents and purposes, look the same.

The progress indicator that you see when you run tests inside Warhol's browser extension is fake. It is somewhat connected to reality, but only just. Significant sections of the data the progress indicator is based on are guesstimates and outright fabrication, but all this deception is there for a reason: it still provides a better user experience than any of the alternatives that you might think of. This article explains why we lie to your users with fake progress bars and how Warhol's browser extension does it. Maybe you too will want to bend the truth at least a little next time you build a progress indicator!

Whether you want to use Warhol or not, having a pattern library is vital to getting your project's design under control. But not all pattern libraries are created equal. Some do a better job at synchronizing your team's understanding of your design system than others and the ones that do the job tend to follow a set of common principles. This article presents the definitive principles for authoring a good, useful and consistent pattern library. It helps you to ensure that the pattern library remains up to date, extensible and actually sees some use by your team.

You know how it goes: your heroic attempt to change the color of something in the top left of your web page not only fails to change the color, but something entirely unrelated in the footer turns green instead. Seen through the fog of your frustration it may appear like CSS is broken, but it is actually working just fine. What looks like a major flaw in CSS is really a feature … and at the same time it is sort of a flaw that anyone working on web frontends has to come to grips with.

Lately we were invited to German language podcast Working Draft to talk about Warhol and design testing in general.

Last week we were invited to talk about Warhol on the (german-language) podcast UI engineering!

The Test Pyramid is a helpful way of thinking about software testing, introduced in 2012 by Martin Fowler. It takes a bird's-eye view on software testing as a whole and asserts that for several economic reasons your project should have more fast and flexible low-level tests (like unit tests) and fewer brittle, slow and expensive high level tests (like integration tests and UI tests).

With Warhol, we appear to be perched at the top of the test pyramid, as we focus on the look and visual consistency of web projects and don't care much about the finer points of business logic. But it is not as clear-cut as it sounds! Warhol shares a few traits with the kind of tests that Fowler placed at the top of his pyramid but can also check low-level design invariants like the color palette — at lighting speed and without much effort on part of the developer. This post explores how exactly frontend UI testing fits into the test pyramid and what Warhol, the new kid on the block, brings to the table.

The web development community loves to argue about boilerplate in Redux applications, but in my opinion the most common complaints are entirely unjustified. Redux is little more than a state machine and the aspects of Redux that people usually get angry about (like actions and action creators) are essential to state machines. You can't build a state machine in any library or programming language without actions and some way to create them. A state machine may be a poor fit for your application or your way of programming, but this is not the state machine's fault. When people complain about "Redux boilerplate" their underlying problem is usually that they picked the wrong tool for the job.

Redux by itself is perfectly fine and (as far as state machines go) not particularly verbose or boilerplate-heavy... at least unless you add TypeScript to the mix.

Warhol helps you to create web-based user interfaces with a more consistent look and feel. In our last article we explained how Warhol works from a technical point of view and what it does to identify design deviations in your project. This post shows what using Warhol actually feels like and how five simple steps are enough to turn your existing pattern library from wishy-washy guidelines into a solid test suite.

Warhol's approach to automated style testing does not rely on pixels but works by analyzing CSS and DOM structures. This enables Warhol to report more than just the fact that something in your styles went wrong. This post comes straight from the trenches of our code base, explains a few of Warhol's internal details and gives you a glimpse into the nature of the diagnostic feedback that you can expect from Warhol.

We are Warhol.

With Warhol we want to make frontend development easier for you. Our goal is to help you to ensure that the components in your web page or app look exactly how you define them in your component library. This greatly reduces style bugs in production. While developing, it makes sure that things look right from the beginning to finish. Our browser extension highlights style inconsistencies as soon as you "create" them. Furthermore our automated services report bugs in each commit and can even permanently monitor your production system.