Open mikesol opened 5 years ago
Dropping this here to track progress!
TODO:
unmock-jest-runner
package that will replace the jestRunner
(https://github.com/Meeshkan/unmock-jest-runner/pull/1) on unmock-jest-runner)0.0.0
version on npmjestRunner
in unmock-js
with new unmock-jest-runner
package (#388)unmock-jest-runner
...
unmock-jest-runner
README.md (https://github.com/Meeshkan/unmock-jest-runner/pull/2)
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.