Custom matcher configuration for Jasmine 7.0.1
0 reputation · 18 Apr 2020, 06:35 UTC
0 reputation · 18 Apr 2020, 06:35 UTC
Goal: Determine whether a custom asymmetric equality tester written for Jasmine 6.x will function correctly under Jasmine 7.0.1 without modification.
Constraints: The project uses Node.js 14 and installs Jasmine via npm; the only published change between v6.3.0 and v7.0.1 is the version bump released on 15 Aug.
Specific questions:
jasmine.addMatchers API remain unchanged between v6.3.0 and v7.0.1?expect extension mechanism that would affect custom matchers?jasmine.addMatchers({ … }) inside a beforeAll or beforeEach block.expect function still resolves matcher names in the same way, and the matcher object must return an object with pass (boolean) and message (string).Jasmine 7.0.1 is largely a maintenance release (the only change from 6.3.0 is a version bump). The core matcher registration and extension logic remain identical, so a matcher written for 6.x should register and execute unchanged. The only differences you might encounter are:
async), it will not be supported because Jasmine’s matcher contract is synchronous.customMatchers.js).
const customMatchers = {
toBeOdd: function() {
return {
compare: function(actual) {
const pass = typeof actual === 'number' && actual % 2 !== 0;
return {
pass,
message: pass ? 'Expected not to be odd' : 'Expected to be odd'
};
}
};
}
};
beforeAll(() => {
jasmine.addMatchers(customMatchers);
});
jasmine.json under setupFiles or spec_files, orjasmine.getEnv().matchers.
If your current matcher uses any asynchronous operations (returns a Promise, uses async, or relies on callbacks), Jasmine 7 will not execute it correctly. In that case you would need to refactor the matcher to be synchronous or use a different testing approach. Please confirm whether your matcher contains any async logic.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 18 Apr 2020, 13:09 UTC
While the jasmine.addMatchers API remains stable, it is important to ensure that custom asymmetric matchers explicitly handle the .not prefix. In Jasmine 7.0.1, the framework relies on the message property returned by the compare function to describe both success and failure.
To maintain consistent behavior across versions, verify that your matcher logic follows this pattern:
pass: true, the message should describe what happens if the test is negated (e.g., "Expected X not to be Y").pass: false, the message should describe why the primary assertion failed (e.g., "Expected X to be Y").If the custom matcher was written for an older version of 6.x and uses a static message, you may find the failure output confusing when using expect(...).not.toMatcher(). Testing both the positive and negated assertions is the most reliable way to verify the migration.