carolstran
commented
4 years ago Dropping this here to track progress!
TODO:
- ✅ Extract runner from unmock-core (#380)
- ✅ Release version 0.3.13 of unmock-js (#381)
- ✅ Build an
unmock-jest-runnerpackage that will replace thejestRunner(https://github.com/Meeshkan/unmock-jest-runner/pull/1) on unmock-jest-runner) - ✅ Release a
0.0.0version on npm - ✅ Replace instances of
jestRunnerinunmock-jswith newunmock-jest-runnerpackage (#388) - Update the following to use
unmock-jest-runner...- ✅ Documentation (https://github.com/unmock/unmock.github.io/pull/51)
- ✅ README.md (#390)
- Koans
- ✅ unmock-examples (https://github.com/Meeshkan/unmock-examples/pull/36)
- ✅ unmock-katacoda-tutorial (https://github.com/unmock/unmock-katacoda-tutorial/pull/7)
- ✅ Katacoda scenarios (https://github.com/unmock/katacoda-scenarios/pull/7)
- ✅ Add proper documentation to the
unmock-jest-runnerREADME.md (https://github.com/Meeshkan/unmock-jest-runner/pull/2)- Once merged, republish to NPM
- Build an
unmock-mocha-runnerpackage. "This is the one that IMO is the most perilous, as we have not yet tested if the abstraction inunmock-runneris 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 inunmock-runner(ie the types) to change. In the ideal case, though, it'll be as short as thejestRunnerand 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
JestAssertionErrorand treat that as the runner failing.JestAssertionErroris an internal, undocumented way thatjestcauses 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 exposeJestAssertionErrorin their external API so that it becomes a bit more sticky and less subject to change.