search

serut / meteor-coverage

Server and client coverage for Meteor
MIT License
54 stars 14 forks source link

path inconsistency running tests in coverage mode #83

Open hexsprite opened 4 years ago

hexsprite commented 4 years ago

Expected behavior: That tests run consistently whether in coverage mode or not. Specifically that stack traces would contain the same paths. These paths are used by testing tools like snap-shot-it to locate associated snapshot files. The stack trace should contain a path to the original test file like: imports/jasmine/server/integration/autosplit.app-spec.js (confirmed with meteortesting:mocha)

Actual behavior: The filename in the stack trace running tests in coverage mode instead looks like /private/var/folders/q5/2qtj1b5n67b_q7czgc5mj8fh0000gn/T/meteor-test-run2kd6s4.yh47s/.meteor/local/build/programs/server/app/app.js

This causes the snapshot to not be able to locate it's required files in the original project directory.

The snap-shot-it package uses stacktrace-js to get the stack trace like so:

fullFilename = `${process.env.PWD}/${stackTrace.getSync()[1].fileName}`;
serut commented 4 years ago

I don't think I can fix this. Maybe the variable process.env.PWD is not the right one to use with meteor-coverage?

hexsprite commented 4 years ago

What causes the inconsistency between coverage mode and non-coverage mode when running tests?

specifically why does it go from correctly referencing the original test file to the combined app.js?

serut commented 4 years ago

I think that's always the case when you run babel-plugin-istanbul or any other coverage library. I use the source map after to retrieve the correct path