Zen and the Art of UI Components Testing

A short walk down memory lane. This is me. Here I just graduated my programming boot which was in the Israeli Army, the Mammran boot camp. We learned a lot of things. The one thing we did not learn is testing. And this is because the year is 1990. And this is the very same year that this book was published by Mycom. And it's talking about succeeding with Agile. And if you dive into this book, you would find this diagram. This is the original test automation pyramid. It talks about three levels. Unit, service, and UI. And you notice that the UI is at the top. Later on, this is evolved into the testing pyramid, which we all know. And the name changed. We still talk about unit test. But we also talk about integration. And the UI test has become end to end test. And this is actually true, because this is what happened for many years. We would see end to end test as a synonym for UI tests.

My name is Tali Barak. I work for a company called Ubiq. And I want to talk about modern approaches to UI component testing, and I call this talk Zen and the Art of UI Component Testing. And soon, we will see what is the Zen and how we can achieve it.

And the first thing, the first principle, is I want to talk about isolations. This is a page, what a web page, a web application looked like back in the 1990s. As you can see, it is quite simple and it is just one page. But then, later on, and we're talking here about 2015, sort of like, we started working in a complete different way when building our web application. We started talking about components.

This is AngularJS, as I said, in December 2015. They are talking about understanding components when you develop an Angular application. And this is from June 2016. This is the actual commit that was made into the React readme. And it started talking also about what it means to be component based. It talks about building encapsulated components that manage their own state and then compose them into more complex UIs. And we still look at components as sort of lego bricks. You have a separate component exhibit. Each one with its own functionality and then you go and you build them into larger UI such as ships, houses, or even a search engine rack server that was built from lego.

Today when we talk about the modern framework for building UI such as Angular React, Vue, Solid, Svelte, etc., they are all built on the principle of component-based. And this is what components let you do. They let you to split the UI into independent and reusable pieces and you can think about each piece in isolation. And when you say think, it's not just about thinking, it's also about building it in isolation and testing it in isolation. In this example here, we can see this is a CodeWe app, a demo app that is built in multiple languages and frameworks. You can just find almost any framework you would like. And you can see here that it is actually using the same component of an article preview both on the global feed and on the MyPost. And this actually implies that if I want to test the functionality of this component, I don't need to go to the specific page of the global feed as I would do in end-to-end test or to login and go into MyPost as I would do in the MyPost page. I can actually isolate this component, put it on separately. And such as we see here, this is the same component, but the page only shows this component. This is using Storybook. Storybook is a great tool for demoing and showing and showcasing components in isolation.

I can see here this is from the same application. I took the editor component. This is when I want to compose an article. And you can see on the same Storybook, I have this component in isolation. And once I have this component, this is zooming in into the component, I can actually test that it works correctly, regardless of which page it is put on. So I can check here that I have my likes, that I can click on them. I can check that the read is actually the reference to the correct URL. I can test here that I'm showing the correct tags, that they are in the right order if there is a specific rule for the order and so on. So point number one is I can test my component in isolation.

The other thing when I talk to people about UI components, how do you test them? They would usually say something. Yes, I want to test the data, I want to test the user interaction, I want to test the layout, I want to test that it raises event and they would use tools like Jest or V-test to test my components. What is important to understand when we are using Jest is that usually we are using not a real browser but we are using what is called a DOM mock. The one at the top is very popular. There is also a newer one that is called HappyDOM. What does it mean working with a fake DOM? When we are building our web application, regardless of component or not, under the hood, it still needs to call the DOM, the document object model, which is the core of how the browser works. And every time we build a component, and it doesn't really matter which frameworks we use, at the end of the day, it will need to call the DOM APIs in order to render the component. We might wrap it in some JSX or TSX or Angular templates or whatever, but under the hood, it still needs to be translated to query selector, create element, set attribute, add event listener, and all the API that we are familiar on the DOM. And usually these APIs are provided by our browser. The browser conforms to the standard of what the DOM APIs work like and we would use it. But what people decide to do with a fake DOM is to actually take other engines that can run JavaScript, and mostly this is Node.js. We have some other engines nowadays, but Node.js is definitely the most popular one. And we build all the APIs that the browser has but in Node.js. But the important thing to understand is yes, we fake the APIs, but we don't really do what the browser does. And this mostly means we are not rendering really the component because this is still fake. It doesn't know how to render components. And what people say very often is that when you're testing your component this way, it feels a bit like playing what's in the box. Because the component, this is a UI component, it has a visual side, but we are not really seeing it. So we are just trying, when we are testing, trying to guess what is inside. We are using tools like enzyme or testing library and so on. But still, this is a lot of guessing game.

And especially when we are working with advanced UI components, UI components that have things like advanced media that have canvases and graphs that is being animated. And we have a lot of micro-interactions and we also have a lot of gestures that we need to support, such as drag and drop or zooming and so on. This is where the mocking of the APIs are played really short. And it's sometimes very hard and you're just trying to make your fake DOM, fake browser work like a browser and you invest a lot of time and it's really frustrating in the test.

Because at the end of the day, it's very simple. When we have UI components, we want to test them in real browser. And this means that it will really render our component. We are not just going to test that we have the right CSS class, but we also want to test that the CSS is building our component correctly and it's actually correctly visualized. We want to talk about network call that is sometimes different when we are working with browser. We want to test the interaction, all the gestures that I mentioned, and also proper timing. When we are working with a mock, it usually does not conform to the timing that the browser really has, or pseudo event and so on. If there are side effects, again, pseudo event is one example, like input change and so on, we want to make sure that it's really triggered correctly, and not us manually triggering, and at the end of the day we might want to actually look at the component and screenshot it and do a visual regression test and make sure that it looks just like we expected it to look.

And over the years, there are a lot of tools that are supporting this kind of browser automation. They usually are a synonym of end-to-end tests, again from this approach, it's saying UI is only being tested in end-to-end. We have Selenium for 20 years now, we have WebDriver.io which is very popular. These are not the only ones. And recently, in the last few years, we have more modern tools like Puppeteer and Cypress, and just probably the latest and greatest addition is PlayWrite together with the newer version of Selenium. And we will discuss how they are different.

So, in order to achieve our second endpoint, we want to make sure that we test in a real browser. The third point for making this testing zen and fun, we want it to be efficient. We want to make sure that we write the test and that they run fast and easy to change and easy to do all the things that we need on top of them. And in order to understand how we can achieve efficiency, let's zoom a bit into the browser. This is what we know as the browser, but this is actually the rendering process of the browser. This is what we see on the screen. It has JavaScript, and now it has also workers. But under the hood, the browser has a lot of other processes like the one that you see here. We have the service worker process. We have network process. We have all the browser processes, things that control security, location, the inputs, getting the input from the operation system and sending it to the browser, and a lot of other parts. The first generation, or what was common in order to test the processes, was to actually run in the JavaScript process inside the browser.

In this way, you could run your test in JavaScript, but everything else was not accessible to you. You could not do a real input, you could not impact location or security, and so on.

The second generation is those fake browsers that I talked about, which are still popular, which basically say we don't have any of this, we are just writing in Node some of the test that we want. And the more modern approach is to have, what we call, an out-of-process automation. All of this part of the browser is actually accessible via APIs. It started as a Chrome developer protocol. And we write an external program that is actually controlling all of these part. This was initiated with Puppeteer in Google. This is what they did as a generic tool that is written in Node.js and it's controlling our browser through this protocol. And later on, the same team that was building Puppeteer in Google has moved to Microsoft and built Playwright. And they extended this protocol, not just for generic browser automation, but actually focusing on what is available, what is required for testing, such as if we have animation, we want to wait until it stabilizes and only then I want to click the button. A lot of the problems existed with all tools like Selenium.

What do we get by out-of-process browser automation? Why is it so good? First of all, we have full access to the file system because this is external and not running on the browser. This is running on our machine. For example in Node.js, we can access any file. We can access the test wherever we want. We can run in parallel. Again, this is a separate program. We don't have any problem running it multiple times as many as needed. Cross-language, it doesn't have to be JavaScript. This automation that is controlling our test can be written basically in any language. You can see that in Playwright, it has Python, .NET, and more. We have full control because we are accessing via the API. We have full control to the security, to the input, to the location services, even to the performance file, and so on. The interactions are real because we're, again, calling these APIs. We are passing interaction the same way that our operating system is sending them. We are not limited to just one window or one tab where our tests are running. We can spawn as many windows and tabs as we want and run the test on top of them.

So, saying all of that, what does that mean for our ZenUI component testing? This is what we are doing at ubiq. We are using a combination of playwright and storybook, as I gave some hints along the way, in order to test our component.

We are using storybook to build our component and to render our component in isolation. We build stories for each component and on top of these stories we are running our tests because playwright does not really care, as long as you give it a web page, it does not really care what's inside the web page. You just need to provide the URL and playwright will open it. So we are spawning our storybook and then on top of it we run the test and we use playwright also for the browser automation.

Playwright started as a browser automation only but it also has now a great test runner that has a lot of really advanced functionality and a great setup, and this is how we actually test our components. This is what it looks like. I'm not sure how useful that is, but you can see here I have it in VS Code and I'm just running the test, it opens the page, it shows me the specific component and I can simply go and see it. Let's see that quickly again. You're running the test inside VS Code. You can see quickly that it passes and the test passes.

So what do we gain from this approach? First of all, this is real component rendering, we don't need to mock anything, the browser is responsible for that. We already write stories for storybooks to show our component so we reuse them and we run the test on top of them. This is a very stable test, we don't need to mock, Playwright is providing a very good feedback Playwright is providing a lot of stability in our tests, we get efficient execution, it can run in parallel, it can run in headless, which means it can run on the CI, it can also shards or you can run it across multiple machines in the CI, you basically have a lot of access to everything, just like any node or program that you want to run. Playwright, and I mean this could be a whole talk about how advanced debugging and tracing can do that. And we get the ability because this is running in the real browser, we can do screenshots and we can do visual regression tests. We can do that in Storybook, we can do that in Playwright and so on. I just want to mention a few other things that they are also doing, Storybook is also advancing their testing capabilities, Playwright has component testing so you can use it not just only for end-to-end and same goes for Cypress, they provide component testing. To make this quick, we can see here that when we talk about end-to-end tests and component testing, we have a real browser and visual migration can achieve this both, but the main difference is this, that in end-to-end we will probably work with a real backend server and make requests to real server and database and we will test complete user flows from ordering to payment, but because they are so long we will probably focus on the happy path while in component testing we will lock our backend, we don't want to go to our backend to run it and there are a lot of tools for doing that and we will focus more on variation and end case.