According to NodeJS v8.x doc:
a falsy assertion will cause an
AssertionErrorto be thrown
console.assert(false) does not throw with v22.4.0 (was working at least with v22.1.4):
// Does not work anymore
expect(() => console.assert(false, 'message')).toThrow('message');
/cc @ranyitz
We had a discussion regarding the subject on #5576.
Specifically, in browsers, calling console.assert() with a falsy assertion will cause the message to be printed to the console without interrupting execution of subsequent code. In Node.js, however, a falsy assertion will cause an AssertionError to be thrown.
Functionality approximating that implemented by browsers can be implemented by extending Node.js' console and overriding the console.assert() method.
That's what we're doing and I think that it's better when console.assert does not throw, like in the browser. If we'll decide differently though - we'll need to detect jsdom/node in the console or create a different console for each.
/cc @thymikee
Might be worth a flag? Not sure
Yep that was our decision. Maybe faulty? I don't have strong feelings about it. @mjesun @cpojer what do you think?
A testing environment (Jest) being more strict than the final running environment (browser) is not a bad thing and probably wanted.
The browser has a different goal: make the end user happy VS a testing environment validates code is rock solid.
Do we want a unit test to succeed even if the code tested contains an assert that fails?
Did you have developers complaining about console.assert() throwing in Jest and not behaving exactly like the browser?
My use case:
In the context of a React library, I use console.assert() as "guards" for internal errors (kind of "constraint programming"), not for the user (for this case there is invariant, throw, PropTypes...).
And I like to test the "guards" are here and working thx to Jest.
function removeItem(itemName) {
console.assert(list[itemName] !== undefined, `Unknown item '${itemName}'`);
delete this[itemName];
}
test('removeItem() with unknown item', () => {
expect(() => removeItem('unknown')).toThrow("Unknown item 'unknown'");
});
These "guards" should never fail in production and can/should be stripped away from the production code.
My two cents on that:
I assume that the console.assert behavior was changed because there were some mismatches or complains before; which means that going all-in into one or another approach will not make either side happy.
Jest is node based, so I would expect that the default behavior matches the one in Node. So by default, the console.assert implementation should throw, as it does in Node. Also, jest-environment-node is the default environment, which makes it consistent with this behavior.
The jest-environment-jsdom, which emulates a browser, should _also_ emulate the console.assert behavior in a browser, to be compliant with what browsers do. Something simple like console.assert = (...args) => console.error(...args) should be enough to mimic it.
@mjesun Actually the default env is jest-environment-jsdom :D https://github.com/facebook/jest/blob/497be7627ef851c947da830d4a8e21046f847a78/packages/jest-config/src/defaults.js#L63
But I agree with the rest. Anybody willing to send a PR with a fix and a test?
馃槅 I'm too used to my internal stuff
Agree with @mjesun and @thymikee, by default the semantics of assert should match the environment being emulated. Sounds like we broke that in node but it's working as expected in jsdom
@tkrotoff to get the assert semantics you're looking for in a jsdom environment, you can override console.assert to the behavior you want. To do that you can add this code to a setupFile:
console.assert = (statement, message) => {
if (!statement) throw new Error(message);
};
That will fail tests like this:

@rickhanlonii
This is what I do by redirecting console.assert to Node' assert:
// File jest.setup.ts
import assert from 'assert';
console.assert = assert;
// File jest.config.js
const config = {
setupFiles: ['./jest.setup.ts']
};
module.exports = config;
console.assert has been changed to not throw in Node 10 (https://github.com/nodejs/node/pull/17706), so all environments now comply with the console spec.
Users of earlier Node versions can use the "polyfill" mentioned earlier.
I think this can be closed.
I agree, thanks for following up!
Most helpful comment
馃槅 I'm too used to my internal stuff