We May Not Need Component Testing

Hi there, how are you doing today? I hope you enjoyed the conference so far. And now let's come to our next discussion.

We may not need a component testing, or do we? First and foremost, my name is Maia Chavin. I'm a senior software engineer at Microsoft Industrial AI. I've also been working in the web and the front-end stack for more than 10 years. I'm a published author with my latest book on LearningView, published by O'Reilly. So if you are interested in LearningView, ViewTree plus TypeScript, check out my book. I'm also a Cloud Native Ambassador, a Vue.js-enabled community organizer, and a Google Developer Expert in web technologies. So you can check out my blog post at maiachavin.com or follow me at Maia Chavin on Twitter or LinkedIn. And that's enough about myself.

Let's take a step back and recap about testing. So testing, the parameter of testing is the most essential parameter that we will use for building any testing system and any application, right? So for this parameter of testing, we have three layers, unit test, integration test, and end-to-end test.

Unit test is considered the most ground-based for all of our application testing, which includes all the independent testable logics that make up to our system, to our applications. And then integration test is to test the data flow between different testable logic modules together, when you connect it together, to make sure that nothing breaks in the middle. And finally, end-to-end test is the most expensive one, with very little test. You can see at the top of the parameter. It's expensive, but it's also very important to simulate the experience of users step-by-step on how they interact with the application before you do the deployment.

And so here comes the next question. Where should component testing belong to? We've been talking so much about component testing, about how we can do it with Playwright, how we do it with Cypress. But what is component testing and where does it belong to? Well, component testing in many aspects has many different meanings. In the back end, it just means a piece of code, a module, a code block in the system that you need to test independently. Meanwhile, in the front end, it becomes more complex. So in fact, component testing, we can divide it into two types. Component testing in small, which is the modular testing, or we can call it unit testing. Component testing in large is meaning you are validating a component with the help of other components, such as a gallery, which depends on gallery item components to render and display the whole list of items. Which means when we test this gallery item, we don't just test the isolated individual component gallery item, sorry, gallery. We have to test it together with gallery items to see if the input and output of one component will be required for testing. Another component will come smooth, and also we need to care about interaction of user, and so on and so forth. So for that, we can say that component testing comes in two types. Component testing in small, unit test. Component testing in large, integration test, or end-to-end test. In the end-to-end test, it really depends on how you define the flow of your individual component testing you're aiming for.

So, which means in the pyramid, come to the question we asked before, where does component testing belong to? So in the pyramid of testing, it's a gray area. In fact, it's a gray area between integration test and unit test. It really depends on what scenario and your goal of testing in order to decide whether the component testing you are trying to achieve is integration or unit test. And that comes to our next question. When are we going to write a unit test for component, and when are we going to write an integration test for each component better, or both? And which technology we should use to do for each scenario? So for that, let's go for our demo app. So in our demo app, we're going to have an application, very simple, a pizza store, which allows users to add to cart, and then update the cart, and also search and update the URL. For the demo app, we're going to perform the testing, comparison between two methods. The first one is VTest with VueTestUtil, and the second one is Playwright component testing.

And here is the package you need to install in your demo app in order to have the testing working, the testing environment working. So VTest with VTestUtil, JSTORM, for Playwright, we have Playwright experimental component testing for Vue and Playwright main package. And with that, we are ready for our demo app.

So let's take a look at our demo app. We have a lot of components in the demo app. Each of the components here will have relevant composables to work with to get data and to update data and to transfer data between each other. We're not going to go through all of these components. We're not going to write tests for all of these components. That is a homework. In this talk, we're going to look at the cart component and the search component.

So for the cart component, we have several features. The cart component, as you may know, is toggleable, which means it can collapse. Whenever you click on the cart, it will display a small popover and tell you how many items you have in cart. And it allows you to remove an item from your cart or remove on the item. And the data it will take from the external composable can use cart.

Okay, so the test case, we're going to write here for each of the method, Playwright component test and VTest. We're going to write the three scenarios, toggle display with or without item and remove actions.

Now let's go for the demo. Good. So, in this demo, we take a look at the cart component implementations. So in here, we can see that we have a toggle button. Okay. And the button will show whether to show the popover or not. So in here, we have the popover. And inside the popover, we also have another if and else, which is whether to display no item or the list item. And we have a button to remove one. Very straightforward. So when we do the test with VTest, when we install VTest, we can have a VTest config on the environment inside here. Or we change our environment for the DOM simulations.

Or we change our environment for the DOM simulations. And we can exclude the end-to-end test from the list so that VTest runner will not take it, will not try to run end-to-end test by accident.

Okay. So let's write our first cart test. So in here, you can see I wrote – I go ahead and I wrote all the selector, also the mock cart items. And I also put some spy for the use cart. And of course, I have to clear afterwards. This allows me to change the different mock implementations for the use cart hook depending on what scenario I want to test.

For the toggle display, the first thing we always need to do is to mount the component. So we do mount, and we just – very simple, mount cart. And then we toggle display, right? So we're going to get the toggle button selector, okay? And then we're going to – first of all, we're going to check that it's not going to display anything that – not going to display the popover. So we're going to do – not away, expect wrapper find cart selector as is to be – not as is. It should be invisible to be formed. Yep. Okay. And then we will do away trigger. We click on the button. And we expect it to be true, but because there's some bug here with the method invisible in view test you do, hopefully they will fix it soon. We will do attribute refine style and make sure that it becomes empty, because when you will be showing it will add the display none as inline style to the component where it's not shown. And that's it. We toggle the display.

Now let's move on to the next step where we're going to render the cart item. For this, we have to modify the cart to have some item in order for us to see the list of items added. So in this one, we first we're going to mock the items that cart buy and we're going to take the total of the length. And we also have to remove not just, we're going to do v, we're going to do add, also v, v.n. We're going to clear with v.n. And of course update non v.n. We don't really care about this.