Add expect.toPass to non-literal value assertions

Do you want to request a feature or report a bug?

Feature

What is the current behavior?

Right now I have to write a test like this:

test('some test', () => {
  const arg = {a: 'b', c: Math.random()}
  const subject = jest.fn()
  subject(arg)
  expect(subject).toHaveBeenCalledWith({
    a: 'b',
    c: expect.any(Number),
  })
  expect(subject.mock.calls[0][0].c).toBeLessThanOrEqual(1)
})

I’d prefer to write this test like this:

test('some test', () => {
  const arg = {a: 'b', c: Math.random()}
  const subject = jest.fn()
  subject(arg)
  expect(subject).toHaveBeenCalledWith({
    a: 'b',
    c: expect.toPass(val => expect(val).toBeLessThanOrEqual(1))
  })
})

I’m fine if we call it something else or if the API is different, but this would be really helpful 😃

Note, with my proposed API you could write multiple assertions:

test('some test', () => {
  const arg = {a: 'b', c: Math.random()}
  const subject = jest.fn()
  subject(arg)
  expect(subject).toHaveBeenCalledWith({
    a: 'b',
    c: expect.toPass(val => {
      expect(val).toBeGreaterThanOrEqual(0)
      expect(val).toBeLessThanOrEqual(1)
    })
  })
})

Thoughts?

[mattphillips]

This API currently exists in jest-extended see toSatisfy.

it("some test", () => {
  const arg = {a: 'b', c: Math.random()}
  const subject = jest.fn()
  subject(arg)
  expect(subject).toHaveBeenCalledWith({
    a: 'b',
    c: expect.any(Number)
  });

  expect(subject.mock.calls[0][0].c).toSatisfy(n => {
    expect(n).toBeGreaterThanOrEqual(0);
    expect(n).toBeLessThanOrEqual(1);
  });
});

Once custom asymmetric matchers is released in Jest then jest-extended can also offer all APIs asymmetrically and the above will become:

it("some test", () => {
  const arg = {a: 'b', c: Math.random()}
  const subject = jest.fn()
  subject(arg)
  expect(subject).toHaveBeenCalledWith({
    a: 'b',
    c: expect.toSatisfy(n => {
      expect(n).toBeGreaterThanOrEqual(0);
      expect(n).toBeLessThanOrEqual(1);
    });
  });
});

[rickhanlonii]

TIL @mattphillips, I missed that one 👍

We’re not going to add this to Jest core right now. We encourage people to use jest-extended, custom asymmetric matchers, and custom matchers, so avoiding them is not a compelling argument to add it to core 🤙