Chainable asymmetric matchers

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

feature

What is the current behavior?

expect({ foo: new Error("failure") }).toEqual({
  foo: expect.any(Error).objectContaining({ message: "failure" }),
})

outputs

    TypeError: expect.any(...).objectContaining is not a function

      548 |           foo: new Error("failure"),
      549 |         }).toEqual({
    > 550 |           foo: expect.any(Error).objectContaining({ message: "failure" }),
      551 |         })
      552 |       })
      553 | 

What is the expected behavior?

The syntax above should not throw.

The following test should throw a descriptive error message:

expect({ foo: new Error("failure") }).toEqual({
  foo: expect.any(Error).objectContaining({ message: "success" }),
})

Please provide your exact Jest configuration

{
  "testMatch": [
    "<rootDir>/imports/**/*.test.js"
  ],
  "testPathIgnorePatterns": [
    "/node_modules/",
    "/.meteor"
  ],
  "setupTestFrameworkScriptFile": "./imports/test-helpers/setup.js",
  "coverageDirectory": "imports/coverage"
}

Run npx envinfo --preset jest in your project directory and paste the results here

  System:
    OS: macOS High Sierra 10.13.3
    CPU: x64 Intel(R) Core(TM) i7-5557U CPU @ 3.10GHz
  Binaries:
    Node: 8.9.1
    Yarn: 1.5.1
    npm: 5.5.1
  npmPackages:
    jest:
      wanted: ^22.4.2
      installed: 22.4.2

[aymericbouzy]

A few things I would like to confirm before coding:

Implementation

In order to have a nice implementation, I suggest:

1/ creating a “combine” operation for asymmetric matchers:

expect("Hello World").toEqual(combinedAssertions([
	expect.stringContaining("Hello"),
	expect.stringContaining("World!"),
]))

2/ adding the chaining API itself

Descriptive error message

I imagined printing the first failing assertion : what do you think?

[cpojer]

That’s a separate conversation entirely. I don’t think it provides a lot of value for the added complexity and it can make assertions harder to read rather than easier.

The nice thing about the extension to asymmetric matchers here is that it allows to create a richer description of what you’d like to match. However, I think we need to be careful if we add this to Jest: expect.arrayContaining(…).stringMatching() and similar combinations do not make any sense.