Component Testing With Vitest

Thank you! Okay, so it's pretty early in the morning though and one minute, yep, it's buffering. How are you feeling today? All good? You have coffee? I actually got a sip of coffee and I'm still very cool. The weather is crazy to me.

Anyway, so before we deep dive into our talk, I just want to repeat what I was talking about myself. So I'm Maya Chavin, I'm a Senior Software Engineer at Microsoft. I'm working for a group called Microsoft Industry AI. So we do kind of like leverage different AI technologies to build industry-specific solutions with JetGPT, GPT, and all this module. I have my book published just two days ago, yes. So if you are and you haven't known Vue before, you want to learn Vue, yeah, check it out. And I was an open source maintainer. You can follow me at Maya Chavin or follow my blog post. I post article once in every blue moon, hopefully.

Anyway, testing. So yeah, we have to test, everyone knows that, right? I have a disclaimer before I move on. I hate tests. Yeah. I do hate tests. Every time when I come to tests, I hate tests. Before I come to test, I say, yeah, everyone have to write test, everyone, literally including me. And I always say to everyone in my team, you got to write tests. But when I go to write test myself, I like, come on, why do anyone want test? Well, you know, we know that we need test, but we always face the dilemma, and that's why we hate test, kind of. Codepay complexity. Anyone who works with a very large code page will know the pain when you need to write test. And you need to write test in order to make sure that your test will only check what happened in your code and not because someone else do something and then it affects your qualities of your code. Testing framework. You're not going to choose framework. What framework are you going to choose? And yes, this talk is about another framework. Yep. I know that. And learning curve.

Every time we talk about a new testing framework, we switch from one testing framework to another because the other one is way cooler and faster. However, we always have a learning curve. Not everyone likes to agree, and not every API looks, feels, or does the same thing. This leads to a specific point of dilemma. Even if you pass all of this, you still need to make sure that your tests cover a minimum of 90% of your code base. If someone decides that 90% coverage is required, then 89% or 99% won't cut it. This can prevent your pull request from being merged, and it can be frustrating. Ultimately, this dilemma comes down to one thing: time. How are we going to allocate time and effort to testing? We need to do it, but how?

How are we going to put time and effort into testing, right? But we need to do it. So, how are we going to do it? Well, before choosing a framework, before going to V-test, we always have to plan. I see a lot of developers that tend to jump into code directly and write the picture, make it work, and then take out the test later. That's actually the wrong approach.

First, we need to decide what kind of projects we want to test. Is it C Sharp? Is it JavaScript? Did I just say C Sharp? Yeah. It's not really relevant to this one, but for Microsoft, I have to talk about C Sharp. Anyway, on this top project, we'll decide what kind of testing plan you need to have. And prioritizations. What are your prioritization here? You want to have fast testing results, like testing process. You want to run parallel. How many parallel workers do you want to run your tests on?

Once, in our team, we had a test run that took about eight hours to complete. That tells you how much complex our code base is. And it comes to the point that we cannot wait for that, and we have to go and evaluate our testing system and add something that reduces it to half the amount. And that's what we've done with Playwright, not Vitex, but it's relevant. Keep the testing order so that people will know what is going on here, what's going on there, which tests failed, and so on. And automate. You don't need manual testing anymore because if you do your automated testing, you write the test, then the whole testing automation will make sure that your code is covered. So everything, when you plan about testing, you make sure that you plan for automation first and foremost. And lastly, all of this comes down to one thing, choose the right tool. Always choose the tool at the bottom. Never choose the tool first and go around it. Because if you go to the tool first, five years later, another tool comes out, you're doomed because you have to do migration and all that. And go back to our metrics here. You probably got used to this metric, right? It's the famous metric for every testing book. It's about having three layers. Unit testing is making testing. You go in to test your piece of code, really, literally piece of code, independent.

Have three layers. Unit test is making testing. You go in to test your piece of code, really, literally piece of code, independent. And integration, when you test all these piece of code together and see if the flow going on correctly. And end-to-end test is just the last piece of the puzzle. Just make sure that the actual user interaction is okay, using the real data is okay.

In this talk, we're not going to discuss about end-to-end test. We're going to talk about integration and unit testing with V-test. But first, the demo.

So in this talk, I'm going to do a demo of a very simple component called Movies. What it does is it has three features. Display a movie gallery. Allow user to fill out the movie by title, by giving an input. And the third one is the movie has to be fetched from external API, which is asynchronous. The code will look kind of simple like that. It's nothing out of the box here. Just a bunch of test sets.

So how we're going to test it? How we're going to test the component, movie component here? Well, for that, we're going to do two things. We're going to test the component logic, which is just a hook. Because I'm using in this one. You can write the whole component with every logic inside. But it's better to split this logic in its own hooks and then test it accordingly and leave the components separately. This way, you will not have to, when the component expands, or when you have to add more features, you won't have to end up with a very long component, and you don't know what it's going to be. And lastly, after you test the hooks, what you can do is just perform what you have to do. It's just perform another sanity component test with all these hooks we're marking. So this way, you have two things. You test the logic, and you test the component based on the assumption that your logic works.

Okay, now that comes to VTEST now. How many people here are familiar with VTEST? So you probably know what is called VTEST or VITEST? Who think that is VITEST? Good. Actually, me too.

Who thinks that is VTEST, the rest, right? Okay, yep. So everyone say VTEST, so that's the meaning. It's like, when I first come to VIT, I thought it was VITE, because we say LITE, so it's supposed to be VITE, right? But then I say, no, it's VIT. So like, what? Anyway, that's the name mean.

So VTEST is what was developed by the VIT team for VIT power, okay, VIT device, VIT, by VIT power projects, but now it's become, it's not just limited to VIT power projects, so it probably can use for other webpack project also. It's a JavaScript and TypeScript unit testing framework, and it just released 1.00 version also two days ago. Wow. So it's stable to use. It's very fast. I can't vow for this, because we use at work, we switch from CHESS to VTEST and it's really, really fast. It's come with TypeScript and CHESSX support out of the box, and of course, the syntax is almost the same with CHESS and Mocha and Chai, and you can use any of them, which means your learning curve, or your migration, will not take that much of effort to do it, but better.

Okay, so how better, let's say, unit test. For unit test, disclaimer here, first and foremost, for unit test, it's important to know that we don't test every unit code. You don't test every piece of code. Every if and else, it doesn't mean you need to test everything of them. If you have to test two plus two equal four, that's fact. You don't test that. So just make sure that you don't override your test. Second thing is, for unit test, always use mock. If anything come outside, if anything you import and not part of the code, you should mock it, because you never know what's going on that, from the other side, can affect your test. And lastly, always make sure that you do functional testing here, that means logic, not everything else, not interaction and so on. Let's take a look about use search, the hook, with the code, the logic behind. So in this logic, I have two things. First is we are going to fill out the list of input item according to the search. So this is the two main logic here that I need to test separately. So for that, for testing the hook, VTest wouldn't work out of the box with React hooks. Because VTest is for JavaScript and TypeScript plan, the vanilla one. If you want to test something special like hooks, because interactive, you need to make sure that you need to use external library to help with that. So in this case, using testing library React hooks is the package that allow you to mimic and render the React hooks according to React standard, and then you can test on it. So how we do that? First, we just import render hook from testing library React hooks, and then we've run the function, trigger the function to render the hooks in the context of React, and we get back the result, and the result has the field called current, where you can� sorry.

Where you can assert like any test, any normal syntax. You can hear that I search expect result.current.search term to be� whoa. It doesn't highlight. That's funny. Never mind. Okay. Okay. So for user, the second one is� why? Never mind. This technical issue. Sorry. I need to test it before I put it here. Okay. So that's one of the use case for users when you test whether it's� how you render the hooks.

The second one, when you want to test the interaction of the hook, let's say you call a function and you expect the internal of the hook, some reactive data going to change, that you can use the app functions from render hooks package, and then it will make sure that it will wait until� it will trigger this function in part of the context of the hook, and then it will make sure that before it moves to expect, we have this cover and it will not throw you any error about reactive item is not updated or something. And that's it.

And the reason why I don't talk about all the VTest syntax here, because it's similar to Chess here. You probably expect to be it, everything is status� you probably have is the import expect it described from VTest. If you look at the first slide� oh, it worked. Yeah. So you have the first slide here, expect it described from VTest. And that is the modular kind of features from VTest allow you to import specific function and make it not like� you don't have to import the whole package, and we're not available globally. Of course, you can make it available globally using the configuration. But if you don't want, this is the way. Make it much faster this way. Okay. Move. Yep. Yep. Okay. So, this is the example how you can write the test.

And you can also run the test using the Test Explorer here with the VTest extension for VS Code. And you probably can also try to copilot writing the test for you, like I'm doing here.

Okay. So, next, action testing. What does that mean? In the use movie hooks, we have� we have one code called useEffect, where we're going to do synchronous performing the actions of fetch movie, which is asynchronous code, which means it will not stop. It will not wait for this code to finish. But it will update one� because we have a useEffect, so it will update when it's finished. I'm sorry. It will update when it's a test movie. And this is how you do the asynchronous code inside synchronous code in a React hook.

Now, how we're going to test it. It's more complex and not trivial using from the previous test we have. What we do here, we have to mock the global fetch with V.fn, a false function. And then that's actually not a good approach also, because you literally mock the whole global implementation of fetch function. And if someone writing another test, they're using global fetch and they also mock it, that means you probably end up having either one of the tests will fall, depending on the race condition here. So the better way to spy on it using V.spy on, and this will make sure that it will attack a spy on function on that global fetch and will allow you to perform more mocking. And the third one, we're going to mock the return value of fetch. And we're going to flush all that synchronous code with Wave 4. In the previous version of testing library React hooks, they're using Wave 4, the next update. But a month ago, they changed it to Wave 4. I think release and deprecate Wave 4 next update, so you should use Wave 4, and just wrap the on the expect code line into the Wave 4, and it will make sure that Wave 4 this to be true or to be asserted within the time frame. And lastly, you trigger the function in hooks and assert it. How does it look? So here, and here I'm going to comment out the global fetch. And then I create a function to the mock result value. And then this function will just, I can reuse another component. It will just return to me a kind of mock result for the fetch value. For the fetch call. And I'm calling the fetch, I create a fetch spy function. And before my test, I will try to mock, to hook the spy, and with the mock value inside my test, which I'm using before on. But if you have different test with different mock result value or mock reject value for the fetch mock, then you can do it inside the test itself, not before on.

And even if you do that, you also need to clean it up afterwards. So here you can see that I do Wave 4 on the promise. I render the hook, I get the result, I get a function called Wave 4 next update. But obviously in the next, if you use it, you should change it for Wave 4. And then assert it and run it. And that's it. It worked. I mean, I don't do live coding, but you got the idea.

Okay. So next one, integration. So we talk about logic tests. So we finished with the testing of all the functional, all the logic we have in the component. Now we're going to do the second one, the sanity test, the actual component test here. Again, VTest doesn't work by itself because the React component is not regular JavaScript function that you can test it. So for that, we combined it with external library called TestingLibraryReact. And this component, this package will give you the render function that allow you to mimic and render a component in the React environment. And then VTest can assert the result from that environment. How to do that? We have two things. Setup. So VTest, you need to set up, you need to extend the expect function with the matcher from the test dome matchers of TestingLibrary. So that expect can compare between snapshot or can compare between the different API inside the React dome. And then you hook into VTest config with the setup file. And then just render it. Import the render from TestingLibraryReact. And then render the function with the component get by test ID. And lastly, expect tested. Simple as that. And that we have our component, the first test for our component testing done.

So why do we need to split the logic per component? Well, as you can see, you can put everything inside. But then testing will be hard because you have to put all the tests inside one file.

And the giant chance here, you change something in the search, it will only need to be retested on the search. And you don't have to run the whole test on the component itself. And we have less code to perform the five. And lastly, make the component testing become more isolated. And you only need to test the sanity test and accessibility test. These are the two main things. Interactions, UI interactions, mimicking and accessibility. That's component test supposed to be for.

Coverage. I think I'm running out of time. So for coverage, 80% or 90%, which one is nice? Well, you need to decide it yourself. My advice is nothing more than 80% for the coverage. And if you want to use coverage with the VTest, you can install the additional package for Istambul from VTest and then hook it to VTest at one of the providers. And voila, you have the test coverage. Also in HTML. And extension for VTest and VS Code. I use that. Because it's very nice to use it. And that's it.

What? Other tool you can try to check out to use with VTest itself. HappyDome. The rumor has it that it's very good. Better than ChessDome. I never tried it. But you should try. And let me know if it's really good. The rumor has it. Xscore React. This is the library for accessibility testing that we use for React components. And you can hook this one inside either Playwright or VTest.

And you can test. Perform the sanity accessibility test. It doesn't cover everything. But it makes sure that your code will follow some semantic WarioArea compliance.

And what next? Before we finish. Plan. Always. Plan your test. First. Code later. You don't have to go for TDD or any other methodologies. Just have an idea of what you're going to build. What you want to test before you start working on it.

Split the component logic. I like the fact that I don't want my component to be big. If it's more than 100 lines of code, you probably should split it. Mock responsibly. Don't try to mock it so that your test will pass in any case. And locator. You can use class or ID. But I prefer to use data test ID. So it will stay mostly stable. And no one will ever even want to try to mess up with it. And last. Add score for accessibility testing, if you haven't done it yet. And thank you.

So we have a few questions that have come out. And a lot of them are actually based in comparisons. I might consolidate some of these questions into just generally, you know... Would you suggest using... Did we say vitest? What did we land on? Did you... I actually don't remember. Would you suggest using vitest for web component tests? And if you do, what would you suggest the benefits are beyond speed when compared with playwright or Jest or other test runs?

First of all, I haven't write a score web component yet. So I cannot... So don't take my word for this, because I kind of assume the web component is similar to normal JavaScript. So you definitely can test with vitest. Well, maybe I should ask it on Twitter, because I have no idea. But either way, I'm sure that you can combine this at vitest itself. It's just a testing framework for... Unit testing framework. So it's... So you can test a normal JavaScript or TypeScript code on that. But things like web component, you have to use with an extra library to help render the component or, you know, combine it to be able to test it. So you should try it out either way. And it's not because of... Would it be better than playwright? Well, the thing is, vitest and playwright are not the same. Vitest is unit test. Playwright for end-to-end. So you can combine these two to make it into a full testing system. So you have playwright to do the end-to-end test. And after you already have your code covered by unit test, by vtest. Yeah, that makes sense. Thank you.

Another question that's come in is... This one might be a fairly clean cut question, if you know the answer to it. But does vitest use JS DOM to render components when testing? Not exactly.

JS DOM is not for rendering. A JS DOM is to get you the API for the DOM API, like a mocking DOM API. So you can get selector, or you can do get attribute by ID or by... I'm sorry, not attribute. Get attribute, something with the DOM API. So usually, yes. By default, vitest uses JS DOM. You can change to happy DOM also, if you want. It's configurable, yeah.

Excellent. Thank you. There are so many great questions, and we simply won't have time to ask them all. I have a really quick one, which is one of the things you mentioned in your talk was the kind of interoperability between what people may already be using for testing and vitest. Have you, on the inverse, ever experienced any quirks where actually, I am having to do a bit more manual work here. It's not just a drop-in replacement. You talked... So let me get this understood correctly. So you were asking that, if I have already my testing system in a different framework, and now I want to switch to vitest, and did I have any fracking moment where it doesn't work out the box?

Exactly. One of the things you mentioned in your talk was the ease of migration between systems. On the inverse, is there any times where that... Yeah, there does have some aha moment there. For example, some function in Chess that I don't remember exactly which function. I think something related to mock. So I got one time I have to migrate the test with the mock test. The test that we have a lot of mocks. And the Chess have special mock function that you clear the debounce, use it for mocking debounce. And I couldn't find the similarity function that I can use it in vitest. So it took me about a day or so to find a workaround. But that was when vitest was 0.0 something version. So I'm sure that they will fix it already.

Excellent. Thank you so much. There, honestly, are so many questions and we've just about run out of time. But for those of you joining us in the room, this will be live stream later. But for those of you joining us in the room, all the speakers today, after their talks, will head over to the speakers question area, which is kind of near the entrance.

So I want us to give a huge round of applause to Maya. And if you want to continue to ask questions, please do head to the speaker questions area afterwards. So time for a round of applause. Thank you. Thank you.