You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 30, 2022. It is now read-only.
Currently, unmock hardcodes Jest error catching in the runner, which means that the runner will not work in mocha and other frameworks.
It would be great if the runner had conditionals for different frameworks, which would require testing different test failure cases for different packages and handling them in a similar manner.
The ugly thing about the way we do it is that we catch a JestAssertionError and treat that as the runner failing. JestAssertionError is an internal, undocumented way that jest causes tests to fail, so essentially we are creating a dependency on an internal API that could change in subsequent versions. It would be nice to address that to, and part of that could be asking the jest team to expose JestAssertionError in their external API so that it becomes a bit more sticky and less subject to change.
The text was updated successfully, but these errors were encountered:
Build an unmock-mocha-runner package. "This is the one that IMO is the most perilous, as we have not yet tested if the abstraction in unmock-runner is powerful enough to handle what mocha needs. For example, mocha may have some error validation scheme or return values from tests that require the abstraction in unmock-runner (ie the types) to change. In the ideal case, though, it'll be as short as the jestRunner and everything will work." - @mikesol
Currently, unmock hardcodes Jest error catching in the runner, which means that the runner will not work in mocha and other frameworks.
It would be great if the runner had conditionals for different frameworks, which would require testing different test failure cases for different packages and handling them in a similar manner.
The ugly thing about the way we do it is that we catch a
JestAssertionError
and treat that as the runner failing.JestAssertionError
is an internal, undocumented way thatjest
causes tests to fail, so essentially we are creating a dependency on an internal API that could change in subsequent versions. It would be nice to address that to, and part of that could be asking the jest team to exposeJestAssertionError
in their external API so that it becomes a bit more sticky and less subject to change.The text was updated successfully, but these errors were encountered: