Component Testing With Vitest

Rate this content
Bookmark

Testing is important. Proper unit tests can eliminate the chance for bugs to appear. But which testing framework will be suitable? Let’s explore how we can develop a reliable and efficient strategy for component development and testing with Vitest

Maya Shavin
Maya Shavin
29 min
07 Dec, 2023

Comments

Sign in or register to post your comment.

Video Summary and Transcription

This Talk explores the challenges of choosing and learning testing frameworks, emphasizing the importance of planning, automation, and prioritizing unit testing. The VTEST framework is introduced as a fast and stable option for unit testing JavaScript and TypeScript code, with a focus on logic and mocking external dependencies. The Talk also covers testing React hooks, integration testing with TestingLibraryReact, component testing, and achieving code coverage. Best practices include performing accessibility tests, planning tests before coding, and using data test IDs for stability.

Available in Español

1. Introduction to Testing Frameworks

Short description:

Thank you! I'm Maya Chavin, a Senior Software Engineer at Microsoft working with Microsoft Industry AI. I hate tests, but we know we need them. Codepay complexity and choosing a testing framework are challenges. This talk is about another framework and its learning curve.

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.

2. Challenges of Testing Frameworks

Short description:

Every time we talk about a new testing framework, we switch from one to another because it's cooler and faster. But there's always a learning curve. Not everyone agrees, and APIs differ. The dilemma is ensuring 90% code coverage. If not, PRs won't be merged. It all comes down to time. How do we allocate time and effort to testing?

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?

3. Planning and Automation of Testing

Short description:

Before choosing a framework, we need to plan and prioritize our testing process. Running tests in parallel can save time, especially for complex code bases. Automating tests ensures code coverage and eliminates the need for manual testing. When planning for testing, always prioritize automation and choose the right tool. Unit testing is crucial for testing individual pieces of code.

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.

4. Testing Layers, Component Demo, and VTEST

Short description:

Unit, integration, and end-to-end tests are the three layers of testing. In this talk, we'll focus on integration and unit testing with V-test. We'll start with a demo of a simple component called Movies that has three features: displaying a movie gallery, allowing users to fill out a movie by title, and fetching movies from an external API. We'll discuss how to test the component logic separately using hooks and then perform a sanity component test. Lastly, we'll touch on VTEST, a topic familiar to some of you.

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.

5. Introduction to VTEST Framework

Short description:

VTEST is a JavaScript and TypeScript unit testing framework developed by the VIT team. It's fast, stable, and supports TypeScript and CHESSX out of the box. When it comes to unit testing, it's important to prioritize logic and use mocking for external dependencies. For testing React hooks, you can use the testing library React hooks package to mimic and render the hooks in the context of React.

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.

6. Testing with VTest Framework

Short description:

You can assert like any test, any normal syntax. For user, one use case is testing how you render the hooks. Another use case is testing the interaction of the hook, where you expect reactive data to change. VTest syntax is similar to Chess and allows you to import specific functions. This example shows how to write the test.

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.

7. Action Testing and Mocking

Short description:

You can run the test using the Test Explorer with the VTest extension for VS Code. Action testing refers to performing asynchronous code inside synchronous code in a React hook. Testing it requires mocking the global fetch using V.fn or spying on it with V.spy on. Mocking the return value of fetch and flushing synchronous code with Wave 4 is also necessary. Finally, triggering the function in hooks and asserting the result completes the testing process.

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.

8. Testing with VTest and TestingLibraryReact

Short description:

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. It worked. Next, we move on to integration testing. We combine VTest with TestingLibraryReact to test React components. We set up VTest with the matcher from TestingLibrary to compare snapshots and APIs. Then we render the component using TestingLibraryReact's render function and assert the result with VTest. Splitting the logic per component is necessary to facilitate testing, as putting all tests in one file would be challenging.

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.

9. Component Testing and Coverage

Short description:

You change something in the search, it will only need to be retested on the search. No need to run the whole test on the component itself. Component testing becomes more isolated. Test the sanity test and accessibility test. Coverage advice is nothing more than 80%. Install the additional package for Istanbul from VTest for coverage. Other tools to check out: HappyDome and Xscore React for accessibility testing.

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.

10. Testing Best Practices

Short description:

Perform the sanity accessibility test to ensure code compliance. Plan your test before coding. Split component logic if it exceeds 100 lines. Mock responsibly and use data test ID for stability. Add accessibility testing score. Thank you.

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.

QnA

Vitest for Web Component Tests

Short description:

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? Vitest is a unit testing framework for normal JavaScript or TypeScript code. For testing web components, an extra library is required to help render and test the components. Vitest and playwright serve different purposes, with vitest focusing on unit testing and playwright for end-to-end testing. They can be combined to create a comprehensive testing system. Another question is whether vitest uses JS DOM to render components when testing, and the answer is not exactly.

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 and Migrating to VTest

Short description:

JS DOM is not for rendering. By default, vitest uses JS DOM, but you can change to happy DOM. There may be some quirks when migrating from a different testing framework to vitest. For example, the mock function in Chess had a special debounce feature that I had to find a workaround for when migrating to vitest. However, this was in an early version of vitest, so it may have been fixed already.

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.

Conclusion and Q&A

Short description:

For those joining us in the room, this will be live-streamed later. After the talks, all speakers will be available at the question area near the entrance. Let's give a round of applause to Maya and continue asking questions in the speaker questions area. Thank you!

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Test Effective Development
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Top Content
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
The Art of ‘Humble Views’: Testing React Native Apps the Smart Way
TestJS Summit 2023TestJS Summit 2023
32 min
The Art of ‘Humble Views’: Testing React Native Apps the Smart Way
In this talk, we explore the divisive world of testing, where developers often find themselves torn between writing no tests and striving for 100% test coverage. Learn how to navigate these polarizing positions and adopt a more nuanced strategy that makes testing efficient and effective.We'll dive into the concept of 'Humble Views,' where we minimize untestable objects by extracting logic from UI elements into test-friendly parts of the codebase. This approach simplifies testing, focusing on business logic instead of UI complexities. Discover how the Model-View-Presenter (MVP) architecture helps achieve this, with presenters serving as a logical layer for testing and hooks aiding in separating logic from UI components.Throughout the talk, we'll discuss the trade-offs of this approach, the role of End-to-End (E2E) tests, and how to strike the perfect balance between too much and too little testing. Join us as we delve into the art of creating 'Humble Views,' ensuring that our React Native apps are scalable, maintainable, and effectively tested!
We May Not Need Component Testing
Vue.js Live 2024Vue.js Live 2024
26 min
We May Not Need Component Testing
Testings are mandatory and unit tests are the foundation for building a good testing system for our project. But for front end projects which involve components, how many unit tests are considered efficient and not overkill? Should we use additional libraries like Testing Library or Vue Test Utils with Vitest to test a component, when we can perform the same with just Playwright? Whether a component test using an E2E framework like Playwright is really a kill for? Let's find out in my talk.
It's a (Testing) Trap! - Common Testing Pitfalls and How to Solve Them
TestJS Summit 2021TestJS Summit 2021
20 min
It's a (Testing) Trap! - Common Testing Pitfalls and How to Solve Them
It’s a trap” - a call or feeling we all might be familiar with, not only when it comes to Star Wars. It’s signalizing a sudden moment of noticing imminent danger. This situation is an excellent allegory for an unpleasant realization in testing. Imagine having the best intentions when it comes to testing but still ending up with tests failing to deliver you any value at all? Tests who are feeling like a pain to deal with?
When writing frontend tests, there are lots of pitfalls on the way. In sum, they can lead to lousy maintainability, slow execution time, and - in the worst-case - tests you cannot trust. But it doesn’t have to be that way. In this session, I will talk about developers’ common mistakes (including mine), at least from my experience. And, of course, on how to avoid them. Testing doesn’t need to be painful, after all.
How to Catch a11y Defects During Unit and E2E Testing
TestJS Summit 2021TestJS Summit 2021
7 min
How to Catch a11y Defects During Unit and E2E Testing
For developers, it is better to catch any a11y defects during unit and e2e testings. This talk is going to show how to automate a11y testing using jest and cypress.
Unit Testing Angular Applications
TestJS Summit 2022TestJS Summit 2022
24 min
Unit Testing Angular Applications
Angular offers many things out of the box, including various testing-related functionalities. This presentation will demonstrate how we can build on Angular's solid unit testing fundamentals and apply certain patterns that make testing easier. Topics covered include: test doubles, testing module pattern, harnesses, "recipes" on how to test some common cases, and more!