Fix incorrect console handling in Jest tests
Currently, we're mocking console.warn
and console.error
to throw in test suite. This is wrong for many reasons:
- throwing inside third-party libraries (like Apollo which complains with
console.error
when some field missing) makes code take different path compared to real world usage - some our tests are built around concepts of components, throwing errors (for example props validation) when in real usage that will be just
console.warn
/console.error
call
Such approach of throwing greatly complicates migration work during vue3-migration because warnings/errors generated by Vue internals / lifecycle hooks are converted to exceptions, blowing up entire test suites (not even tests)
Related to: Ensure all jest test suites could be run with @... (#390830 - closed)
Implementation plan
As the most boring solution I suggest using jest-fail-on-console package It implements quite complex non-trivial logic on respecting console messages at different test phases (like teardown, etc., etc.) and I see no reason to reimplent this logic ourselves
We should use silenceMessage
functionality from this package to silence all existing errors (basically this will include huge if-else
) - we don't want to introduce new console.error
but fixing previous instances are outside of the scope for the first iteration.
However, even after this fix certain tests will fail - mostly because we were relying on throwing on console.warn
/ console.error
as system behavior. One of the most notable situations is code checking custom validators logic in Vue.js by passing incorrect props to component and expecting it to throw
(because Vue will call console.error
/ console.warn
internally complaining about invalid prop or failed validator).
However, with throwing behavior removed Vue.js will try to render component with invalid props passed usually resulting in render blowing up (which is bad). I suggest creating new helper, which might look something like this:
import { assertProps } from 'helpers/vue_assert_props';
// ...
expect(assertProps(GlComponent, { prop1: 1, prop2: 2: }).toThrow(...)
underneath assertProps
will make a copy of GlComponent and handle "throwing on invalid props". So the very first step for dealing with this issue will be setting up such helper and writing docs for it