vim-test / vim-test

Hello,

I would like to run some of my tests with --coverage enabled, but the jest strategy is forcing --no-coverage as an argument to the command. Is there any way to make this customizable without setting up a custom strategy?

-- Adding the flag has no effect, because `--no-coverage` is already set and will result in
-- jest --coverage --no-coverage --runTestsByPath -- src/example/example.spec.ts
vim.g['test#javascript#jest#options'] = '--coverage'

Thanks for the plugin and helping out.

Reference:

vim-test/autoload/test/javascript/jest.vim

Line 21 in 63d317c

return ['--no-coverage', '--runTestsByPath', name, '--', a:position['file']]

Thank you for pointing out this. I am inclined to remove the default of --no-coverage as one shouldn't force this upon the user. Instead, people could set let test#javascript#jest#options = '--no-coverage'

@mpareja I know you introduced with #291 for TestNearest, is this still needed or could it be set via an option? @janko any thoughts on this?

The other option, though it introduces more complexity in the code, is to check if coverage appears in the user set options and let it override.

I've got a bunch of thoughts, but before I get into them...

@codeinabox It's been a while since I looked at this project. Would it be difficult to inject the custom options in between our defaults and the file specs? i.e. the final command line being jest --no-coverage --coverage ... which works because jest respects the later argument

It wouldn't be difficult, in theory it would be a case of adding logic that checks if coverage has been set in the options and if so it wouldn't be set it as part of the hard coded options.

However, after revisiting the pull requests to default to no coverage and also the issues that have arisen, it has resulted in an opinionated approach for Jest coverage. Removing this logic would leave it up to the user and also reduce the code complexity. So the question comes to down whether vim-test should run tests in an opinionated way or not.

The spirit of vim-test is zero configuration required, but I'd argue it should not be opinionated in this configuration.

I should also add that of all the runners that are supported, and there a lot these days, only Jest and Vitest have this opinionated approach to code coverage options.

I'm okay with removing --no-coverage.

The spirit of the --no-coverage change came from the near-certainty of failure when running TestNearest w/ coverage. For me, this was amplified by Jest's configuration model supporting specifying collectCoverage: true. In hindsight, I think a sound way forward would be for people to avoid using collectCoverage: true in their jest settings and passing --coverage explicitly when appropriate for the context, like when the full test suite runs or when someone wants to gauge coverage for a particular file (as in this ticket).

As the Jest configuration defaults to collectCoverage: false, I will proceed with remove the behaviour to default to --no-coverage

Thank you very much for helping out, @codeinabox.

Jest: Overwriting Coverage setting