Now that you've got a good grasp on why testing is important, let's talk about why you should reach for Vtest in order to do that testing. We won't get into strategy here, but we will talk about the tools that Vtest has to offer, and we'll see how those come together in just a little bit. But let's start by answering the question, why as a V developer should you choose Vtest? Put simply, VEET is the prescribed build tool for Vue, and VTEST is the prescribed testing tool for VEET.
So the choice is really a no-brainer, and there are quite a few reasons why, starting, number one, with its easy and streamlined setup. VTEST uses VEET's config, its transformers, its resolvers, and plugins. Meaning that the aliases, few single file components, typescripts, CSS modules, all the stuff that already works for your build and dev server pipeline, now just work in the same way when you run your tests. This means you don't have to maintain some separate pipeline just to run your tests.
Your vconfig might be as simple as this, or it might not even exist at all. However, VTest has a lot more going for it than this simple setup story. In fact, you can think of VTest as a Swiss army knife, a single tool with lots of little sub tools or blades, if you will, allow me the analogy, that make it super, super powerful. So blade number one in this Swiss army knife is the ability for VTest to run unit tests.
These assert that JS and TS functions, modules, classes, and other language primitives work in isolation. It's basic input-output testing and where a lot of people start, but also where a lot of value lies. They're pretty easy to write and even faster to run. You might also have heard of mocks, spies, and stubs.
They're really not that complicated. They're all just supplementary tools available to keep these unit tests fast and focused on one concern. Unit tests are great for front-end and back-end logic alike. And on the front-end, inside of your view applications, they're also really great for testing composables and stores and even helper functions, composables or stores that reach to the network layer.
That brings us to blade at number two, component tests. For Vue, and indeed other frontend frameworks, testing a component involves mounting it to the DOM, passing known props and triggering user interactions, and finally asserting the rendered output and the events submitted are as expected. In VTest, this is done in a real browser, not in a mock DOM, which, while fast, can miss subtle but essential browser behavior. So VTest lets us test the UI layer without spitting up the entire app.
We hand the component known state, click a button, and then just check what the user should see. By the way, I would also group VTest's snapshot feature in this category that allows you to check the rendered HTML of component against some previous recorded version of that HTML to ensure that nothing has changed. The third blade of this Swiss Army knife is visual regression testing. That same browser mode that enables component testing also unlocks the ability for visual regression testing, where we take a screenshot of a component, compare it to a known good state of that same component, and then fail on some unexpected pixel difference between the two.
This may sound a lot like the snapshot testing, but now we're not comparing raw HTML. Instead, we're actually comparing the visual output, the rendered output of that HTML in image form. The fourth blade in our arsenal is the Fetch API. The test, of course, is built on top of JS and TypeScript.
So the Fetch API just works out of the box, and it works great for testing API endpoints, RESTful APIs, with the same kind of assertions that you're used to using for unit tests. The fifth blade is higher confidence integration and end-to-end style tests. You can actually even run these full browser end-to-end tests inside of Vtest's browser mode. However, at the time of this recording, that's not a fully battle tested solution.
So the test pairs perfectly with Playwright if you need the entire browser automation story. Now these types of end-to-end tests are really great for confidence because they test not only each of the different units or layers of your app in isolation, but they test a full user's journey on a page or through a sequence of pages. so that you can test the seams between all those different layers as one whole unit. That's what makes these tests so beneficial, but also makes them more difficult to write, harder to set up, and slower to run.
So, we will use these types of tests later on in the course very deliberately, but sparingly. For you hardcore TypeScript fans, VTest can even assert TypeScript types. This is useful when you care that a contract type doesn't quietly widen to something overly permissive as changes land over time. Want a quick way to see what parts of your code have been tested and how much of your code is covered?
The next blade is code coverage reports. VITAS has a built-in coverage reporter that just works out of the box. And then finally, the last blade that I want to mention in this lesson, is all the various ways that you can run these tests. You can run them via a CLI locally in watch mode.
Your agents can run them via the CLI. Your CI CD pipelines can run them before deployed or prod. You can run them in a browser GUI, or you can even run them directly in an IDE with official VS code, JetBrains or Wallaby extensions. Whew, VTest certainly has a lot to offer.
I hope this overview has been helpful and that you're ready to start using some of these tools as we move forward in the course.