Chainable Matchers

[zangab]

👋 Hi guys,
we are currently migrating from jest to vitest.
In jest we used a package called jest-chain which allows you to chain matchers that are partially applied (with their own context), so f.e. an isNot is not interfering with a following matcher.

// sample spec, we do have custom matchers defined via expect.extend() though, but to get the picture
expect(80).not.toBeTypeOf('string').toBeGreaterThan(30)
// this would fail, bc the not is also negating the toBeGreaterThan matcher

We put our matchers in a setup file and they are loaded but the ability to chain them is currently missing. As soon as an isNot is set, it's reversing the logic and outcome of the other matchers. How can we achieve this?

This is the source of the chain.js of jest-chain.

Thx.

[sheremet-va]

expect is provided by chai.js, so all the chaining behaviour is identical to it

[Dobby89]

Does anyone know of a compatible package which does this?

[SimonEast]

It's really helpful to be able to chain tests together and reduce typing, but as the original poster mentioned, the .not seems to apply to everything after it, and I cannot find a way to undo it. I'd like to be able to write something like this:

expect(3)
	.not.toBe(4)
	.toBe(3)

But it seems you have to place all the .not tests at the end of the chain, like this:

expect(3)
	.toBe(3)
	.not.toBe(4).toBe(5)

If anyone has found a good workaround, I'd love to hear it.

[SimonEast]

I found a good solution. 🎉

Firstly, understand that vitest is using Chai as the underlying framework, and with Chai, .not applies to everything following it in the chain, not just the next matcher:

expect(3).not.toBe(1).toBe(2);  // this will pass

To continue the chain but stop the .not from applying, you can add a custom property to chai, like this:

import { chai } from 'vitest'

chai.Assertion.addProperty('is', function () {
  this.__flags.negate = false;
});

Now you can write tests like this:

// This test now passes!
expect(3)
  .not.toBe(1).toBe(2)
  .is.toBe(3).toBe(3);

I chose the term .is since it reads nicely and seems to work well from my limited testing, but it's also a built-in property, so if you experience conflicts or other issues with it, you could rename it to something else like unNot, undoNot, clearNot.

Would be good to see chaining and .not described a little clearer in the Vitest docs, perhaps even with this snippet if it proves robust?