Jamaica real time feedback into the behavior of your distributed systems and observing changes exceptions errors in real time allows you to not only experiment with confidence, but respond instantly to get things working again. Clone hey everyone, Andy Knight here, automation panda and developer advocate at applitools. Today I'm going to show you how to run visual tests for your storybook components across different browsers. And you won't even need to write a single line of new test code. Let's learn here. I have a small react app that I developers myself using a storybook component library. I have it running on my local machine. All the different things you see on this app are components which are small, reusable places of the UI. Here I have three examples of components used to build this app, a button, a text input field, and even the scroll button I just clicked. Components are richer than plain old web elements. A web element is simply an entity declared by an HTML tag. A component, however, is a unit of UI. Components are made up of elements. Small components may be a single element with some CSS styling, but larger components like headers and sidebars may use multiple elements in order to make consistent designs. Web developers create component libraries so they can reuse components anywhere in these app without duplicating code or breaking their uniformity. For example, let's say you want all buttons in your app to be round and blue like this one. You could define a component for could blue buttons and use that component everywhere instead of explicitly setting every individual button to be round and blue. Tools like storybook enable developers to build and maintain libraries of reusable components like this. Components, just like any other pieces of code, can change as part of software development. Some changes are intentional, but others are not. What happens if that round blue button becomes rectangular? Or what happens if it turns red? Is that good or bad? Will anyone even notice? Some changes are obvious. For example, if the button accidentally becomes enormous due to a CSS typo, everyone would notice. Not all changes might be this obvious, though. Think about could buttons turning rectangular? Subtle changes can be easy to overlook. We need a way to visually inspect components. If we could compare a good baseline image side by side with the latest checkpoint image these we could easily see any differences. App tools eyes does this automatically for storybook components. It captures snapshots for each story and uses visual AI for comparisons. In fact, you don't even need to create any test cases or write any automated code. The applitools Eyes Storybook SDK automatically creates tests for each story it finds. We could do this testing manually using the storybook viewer, but we would probably miss things. Manual inspection would be difficult to scale with a large component library. It's also a hassle to do cross browser testing for these components. You need to reopen the storybook viewer in different browsers and grind through all the stories again and again. So let's see how to automate visual tests for storybook components using Appletool's eyes. I'll show you the storybook component library behind this app, and then I'll show you how to configure that project for visual testing. We'll run a few tests together and see how they appear in the applitools dashboard. Let's go. So here is the storybook component library for that react app we just saw. I have it opened in the storybook viewer in my browser. As you can see in the left sidebar, there are four components for this library, the button, these header, these scroll button, and the text input. Now, some of these components, such as the button, actually have multiple variations or stories for them. Here we can see the enormous button. We also have a large button, primary color, a rectangular button, and a secondary color. We can also use the different controls to view what the buttons would look like under different conditions. So here I can toggle the rectangular button between the primary and secondary colors. It's nice to come in here and manually test out our components as we're developing them. But keep in mind, as our component library grows, we're going to have more and more things to manually test. And so manual testing isn't going to keep up with the scale of most large web app projects. It'll be much, much better to have our visual testing automated. So here is the source code for that react app. I have the project open in vs code under source. You can see all of the stories for the different components in our library, as well as the app's main page and all that other react stuff if we want to add applitools eyes Storybook SDK to this project. Thankfully, we don't need to muck around too much with code. One thing we need to do is we'll need to add the Applitools Eyes storybook package to the project. Now, I've already done that, so you'll see it here in package JSOn. But if you wanted to install it into your own project, it's as simple as NPM install and then the name of that package. And you can do that for any project that has a storybook component library, whether that's react angular view doesn't matter. Now the other thing I need to add to my project is a config file, and that's here at the root project directory level. Appletools config js. Inside of this put a module exports objects, and add the following settings. First, you'll want to set a concurrency setting that will dictate how many parallel visual tests can run in the app tools Ultrafast test cloud. Note that if you're using an app tools free account, you'll be limited to one level of concurrency. Secondly, you'll have the batch name, which refers to the collection of tests that you will be launching at one time. So that way when you go to the app tools dashboard, you can see a helpful name for all the tests you have. I'm going to call this visually testing storybook components. The only other thing you need to do this kind of testing is an Appletools account. You can go to appletools.com slash register and sign up for a free account. Just to get started with your account. You'll get something called an API key, and you'll need to set that API key as an environment variable like this applitools API key equals and just paste whatever that key is. Now I'm going to keep mine secret because I don't want you running tests on my account. With those few things set up, it's time to run some visual tests. So from your project directory, run the visual tests using the following command, NPx eyes storybook, and you'll also need to give it the static directory of files, in my case, the public directory using the S option and let's run it. What this will do is it will start up storybook and the eyes SDK will look for all of these stories inside of it. Then it will perform the visual testing on each story it finds. So in our library we had four components, but it had a total of nine stories. Once all those stories are found, it will run the visual tests in the ultrafast test grid and it will upload the results. Here you can see a spill out for all of those results. There are those five stories for the button, each one with its name tests on chrome under the default viewport. We also had those two header, one scroll button, and one text input. And notice how all these were reported as new. New means it's establishing new baseline snapshots for each of these stories, and you can go to the applitools eyes SDK to see these results. All you got to do is click this link. When we visit the applitools dashboard. We can see that our batch of tests for visually testing storybook components has been uploaded to the dashboard. And in here, we have all nine of those new snapshots. So it's taking those baselines that we'll say are good, and we'll use those for future comparisons. You could even open them up to see what the baselines look like. For example, here's the baseline for the header. All good. Let's try running these tests again to see what happens when we take our first checkpoint. So back in our terminal in vs code, let's run the same test again with no changes to anything. Again, same thing happens, starts up storybook, identifies all the stories and will perform the visual testing on each of the nine stories it finds. And it does it pretty quick, thankfully. All right, so again, we have those nine test results, and now instead of saying new, each one is saying passed. Let's go look at those results in the dashboard again. Now, when we go to the app tools dashboard, we see that second round of tests having been uploaded, and they're all reporting as passed. They're not new anymore because we had baselines before they're passed, because applitools compared the checkpoint images to the baseline images. If we open them up, for example, like with the header here, we can visually compare the baseline with the checkpoint side by side. And upon visual inspection, it's obvious nothing has change. Therefore, all of these are good, and applitools marked them all as passed. Now, let's run our tests a third time. But first, let's introduce a visual change and see how Appletool's eyes identifies it. So let's turn our nice blue button into a red button. If we go into our stories and we go into button CSS, we can see all the css for styling those buttons. Let's tweak the class for the primary color instead of blue. Let's make it red. Nice flaming hot red. All right, let's save that. Let's run the tests again. Uhoh, what happened? So we can see that there's a little x by our nine of nine stories. And when we see the printout of the results, seven of the tests have passed, but two are marked as unresolved. Let's take a look in the dashboard. So here in the dashboard, we can see our latest catch had two unresolved test pages. Now, unresolved means that app tools has identified a visual difference, and it needs you as the human to come in and determine if that's good or bad. Remember, some visual changes can be okay if they were deliberately intended by the developer, but others may be bugs that happen accidentally or unexpectedly. So let's take a look in one of these. So here we have the visual snapshots for the primary button and if we open them when we compare side by side we can see there's a clear visual difference. The one on the left, the baseline is blue. These these one on the right is red. And Apple tool's eyes also highlights the differences for you in purple. So here we can say if this is good or bad. If it's good we can give it a thumbs up. And these, the latest checkpoint becomes the new baseline image against which future checkpoints will be compared. Or we could say this is a bug. And so at that point we would give a thumbs down and then the original baseline is kept and this one is seen as a failure. Let's say that these change was deliberate and expected and good. I'll mark it with these thumbs up and then what the app tools dashboard will do is it'll take you to the next unresolved test. And so here again we can see the differences in the component. This time we're looking at the header and Appletool's eyes narrowed in on the sign up button on the right being the only thing that change. All the other stuff in the header was the same so nothing was highlighted again. Since this is a good change, we'll say thumbs up and boom. Now our catch results have been updated. Anytime you save new baselines like that, remember to save your results. And now things will be good. And we have new baseline images for those tests. Let's make another change. This time I want to tweak the header. So let's go to our header JSX file and I want to do a couple of things here. First of all, I want to change the title text in the header. Rather than saying visually testing storybook components, let's change it to something else so we can see a text based change here. Also I want to tweak the layout. So if I go to header CSS, notice here in the wrapper, this controls how that layout of left and right with the buttons go. I'm going to be devious. Pretend I accidentally deleted justify content. All right, clearly this is going to mess up the visuals. So let's run the tests again and see what happens. Uhoh, bump, bump. But again, two of our tests are unresolved this time both of these the header component. That's to be expected given the change we made. Let's hop over to the dashboard to inspect. The latest batch has those two unresolved test cases. So let's take a look at them. I'll open one. Let's see what's different. Wow. Pretty much everything. So we can see that not only was the title change, but the buttons were changed. So on the original, the title was on the left and the buttons were on the right. In the latest checkpoint, the title text is different and the buttons no longer appear on the right, but are smashed all the way to the left, right next to the title. We can actually inspect these changes more deeply if we go to preview match level. We'll notice that right now it is on the strict matching level. Strict means app tools eyes is going to look for differences that a human eye would notice. This includes things like content, layout and all the above. But we can change the filter to look at different things. Let's try a matching level of content. What the content does is it looks to see what has changed in terms of the content. Not so much these layout content looking at colors as well as text. And so we can see here, because we changed all those things, it's still highlighting everything. But if I changed it to layout, meaning don't look at tests, only look at the things that have shifted in layout, then we see a much different picture here. The thing that app tools eyes denotes as being different in layout are the buttons themselves, right? The text visually testing storybook components versus mycool site is ignored by app tools eyes. And this can be helpful because sometimes it doesn't matter what these text is in a particular layout or field or grid or whatever you're doing. Maybe it's just these shifting of elements that you're looking for. So you can use these to help determine if this is a good or bad new checkpoint. For me, though, I do care about both layout and content, so I want to keep it on the strict comparison. And to me, the shifting of the buttons is a pretty bad thing. I would see that as a visual bug. So in this case, I'm going to give thumbs down for a failure. We can see in the other story of this component, there's only one button instead of two, but still it's been shifted and I don't like that. So I'm going to thumbs down that as well. Now we can see we have failed results because things were not equal. If I save, that will become saved. And so anytime that type of failure happens again, it'll automatically be logged as failed. What we should do now is we should go back to the code and update it to make sure that things will pass again. Let's do that. And bam. So what I did real quick is I went behind the scenes and I undid the changes and rerun the tests and now we can see everything is back to passing. If I look at those specific header comparisons, we can see boom. Boom. Our baseline was unchanged. Our checkpoint is fixed now. So that's how we can use visual testing to spot bad changes and then use that feedback to quickly make the improvements and fixes, rerun our tests and set everything back to being good. So far, all these testing we've done has been on Google Chrome. But with the Apple tools ultrafast grid, we could test our components against any browsers that we want. The advantage of doing cross browser testing is that we can render all of those snapshots under different configurations and detect if there's any weird differences between them. For example, maybe there's some weird thing with IE or safari that doesn't render our button as appropriately as we would want. And we want to find that. But before our users do another nice thing with cross browser testing for components is that if we have larger components, they may have some aspects of responsive design. So we want to make sure that those bigger components are rendered properly and all their elements appear appropriately, which in isolation is really nice because we can catch that before it spreads out to other pages. Thankfully, the app tools eyes SDK for storybook makes cross browser testing a breeze. All we have to do is update our app tools config js and in here you can see I've added this browser setting with a list of different browser configurations. I have five desktop browser configurations, each with their own viewport size as well as these name of the browser and I have five mobile browser configurations with these device name as well as the screen orientation being portrait or landscape. It's important to test not only different browsers, but also different viewport sizes and orientations. So let's see what happens when we run our nine stories against these ten browser configurations. And boom. Check it out. So here we had many, many more test results, 90 to be precise. And even though we had run some of these stories before for visual testing because they now have these new browser configurations, they have to establish new baselines. So that's why all of the results now are new. If we go to this link, we can see it all in the dashboard. And here are the results. As we can see we have 90 new results across all the different browser configurations we specified. And notice how little time it took this entire catch only took 37 seconds. 37 seconds for 90 tests in a browser is really, really fast. That's why it's called the apple tools ultra fast grid. If you were to do traditional cons, browser testing for these 90 tests could take several minutes, possibly even an hour or more to execute. So cross browser visual testing for storybook components is really, really nice. One more thing I want to touch on is when and where to run your visual component tests. Now, component tests fall somewhere between your integration tests and your end to end tests, because components are like UI units. What I recommend is to run your visual component tests from some sort of CI process. I actually created a GitHub action in this example repository so that I could run them, let's say whenever a pull request is opened. Here is the workflow yaml for my GitHub action. It's pretty straightforward, so there's no reason not to do this. I run it on a Ubuntu image, and to do it you simply check out the code, you set up node JS, you install the dependencies, and then instead of running that command locally like we did before, you just run it here. You will need to configure your project with your applitools API key, but that should be the only input you need. And then you can specify the different steps in the workflow when you want to dispatch these, and they'll run and upload your results to the app tools dashboard. It's pretty nifty, and that's how you can run visual component tests for your storybook libraries. All you need to do is add the app tools eyes SDK to your project, declare some config, and run the tests. You don't need to explicitly write any new test code. If you want to try this for yourself, check out the example code in this GitHub repository and read this article I wrote recently on visual testing for storybook. Again, my name is Andy Knight. You can follow me on Twitter at automation panda. Feel free to hit me up with any questions.