meeshkan/unmock-js

Mocha support in the runner

mikesol opened this issue · 1 comments

mikesol commented

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.

carolstran commented

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-runner package that will replace the jestRunner (meeshkan/unmock-jest-runner#1) on unmock-jest-runner)
  • ✅ Release a 0.0.0 version on npm
  • ✅ Replace instances of jestRunner in unmock-js with new unmock-jest-runner package (#388)
  • Update the following to use unmock-jest-runner...
  • ✅ Add proper documentation to the unmock-jest-runner README.md (meeshkan/unmock-jest-runner#2)
    • Once merged, republish to NPM
  • 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