Skip to main content


Since 2017, I have only used Jest for JavaScript application testing. And while Vitest does look exciting, I think that it’s safe to say that Jest will be around for a good while longer.

Here are some of tips and tricks that I’ve learned that make working with Jest a little better. The headings are organized alphabetically for ease of reference.


Jest’s global test method has an it alias that you might find useful. There is usually a standard in the codebase where I’m working, but I’ve found that tests can read a little more naturally with the alias:

test("When a user is logged in, ...", () => {});
it("Logs an event on interaction", () => {});


There are a lot of matcher functions that are good to know, so I’ll only list a few here.

One of the most useful matchers (and hardest to remember) is expect.objectContaining(). This allows you to assert that certain properties/values are present on the object without needing to mock all of them.

    example: true,

Another handy matcher is not(), which gives you a simple way to negate any matcher:

expect(typeof readableTime).not.toBe("number");

I do recommend skimming the Jest docs for expect occasionally to pick up some new matcher that might help in your next test.


The Jest CLI has a number of flags that can be used to change the way that Jest runs. Here are some of the ones that I find most helpful:

Selective runs

When working in a large test file, it’s nice to run only the cases that you care about. Sometimes that means selecting a specific test or block, and other times that means skipping anything that isn’t necessary at the moment.

To just run a specific test, you can use the only() method on the global describe/test methods. This will ensure that only that code is run:

test.only("This test will run", () => {});
test("This test will not", () => {});

To omit a test from the run, you can similarly use the skip() method:

test("This test will run", () => {});
test.skip("This test will not", () => {});

For a smaller change to skip tests, you can add an x to the front of for the same behavior:

test("This test will run", () => {});
xtest("This test will not", () => {});

If you’re going to use this, I’d recommend a linter rule to prevent you from committing skipped tests.