In 2015, while working at Facebook, I created an open-source library for running Screenshot Tests for Android. That library has became widely popular outside of Facebook.
To understand the value of Screenshot Tests we first have to understand why testing UI is hard. Engineers are often encouraged to focus their attention on unit tests instead of functional and integration tests. We’ve worked with many teams that have tried pure unit tests for UI, but eventually, these tests get brittle and very hard to read.
It’s important to understand the Screenshot Tests aren’t a replacement for Unit Tests. Instead, they complement the Unit Tests as part of the test pyramid.
To give you a concrete example, let’s take a look at Facebook’s Newsfeed, and think of how to test it. You will quickly realize that there are hundreds of Newsfeed story types: images, plain stories, photos, shares, groups. And that’s not all. Just like any other company, Facebook has a core set of UI components UI team that almost everybody else in the company uses.
So if the UI team, say, changes the look of a button, the rendering of almost everybody’s components changes.
This is a problem because frontend developers often make assumptions in their UI based on what these core components look like. It’s important that as soon as the core UI engineers make their changes that all other developers get notified that their components are going to render differently.
At Facebook, we found most of our changes were intentional, not bugs. But it’s still critical to keep everyone updated about the changes.
There are libraries that run Screenshot Tests for Android and also ones for iOS.
So then, why wouldn’t simply use these open source libraries? Where does Screenshotbot come in, and why should you use it? We’ll address that in the next section.
Powered by BetterDocs