Vitest comes with a bunch of commands for running your tests:
vitest,vitest watch,vitest dev: Run your test suite and then watches for changes to either your tests or your code.vitest run: Runs your test suite once and only once.vitest related: Accepts some paths and then walks your import statements to figure out all of the related files. Example:vitest related /src/index.ts /src/hello-world.js.vitest ${substring}: Only runs the files with a filename that contain whatever substring you provide. Example:vitest worldwill run/src/hello-world.test.tsbut not/src/index.test.ts.
--update,-u: Update snapshots.--ui: Opens Vitest UI.--dom: Mock browser APIs using happy-dom or jsdom.--browser: Run your tests in the browser.--api: Serve API. This one supports--api.portand--api.hostas well.
Just in case you're coming from some other testing framework or you testing muscle is just a little bit atrophied—we've all been there—let's start with some super simple tests and we'll escalate from there.
Let's head into getting-started and run our tests for the first time. You can run this test by doing the following:
npx vitestfrom inside of./src/examples/getting-started.- Run
npm testfrom inside of./src/examples/getting-started.
it and test are synonyms. You can (but probably shouldn't) use them interchangeably. I like it. So, that's going to be what I use. But, you're welcome to use whatever you want.
import { expect, it } from 'vitest';
const add = (a: number, b: number) => a + b;
it('should work as expected', () => {
expect(add(2, 4)).toBe(6);
});You didn't ask, but here is my general heuristic: If I find myself starting every single test name with the word "it", then I'll use it. If that feels awkward, the I'll use test. But, at the very least, I'll try to be consistent in whatever file I'm working with.
Warning: One thing to keep in mind is that if you test has no failing expectations, then it is a passing test. The twist, of course, is that if a test passes, it could just be that none of the expectations were called. We'll revisit this when we cover Testing Asynchronous Code. This isn't a Bad Thing™ and will come in handy down the road.
Let's talk a bit more about Why Tests Pass and Fail.