Instrument spawned processes with ts-node

[kirinnee]

Can Vitest instrument ts-node subprocesses spawned by spawn or exec?

The use case is integration testing for CLI applications.

I recently swapped from mocha-chai to Vitest and the coverage half-worked.

vitest config:

import { defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    name: "Integration Test",
    dir: "tests/integration",
    include: ["**/*.spec.ts"],
    reporters: ["html", "json"],
    testTimeout: 30000,
    outputFile: {
      html: "test-results/int/html/index.html",
      json: "test-results/int/result.json"
    },
    coverage: {
      all: true,
      include: ["src/**/*.[tj]s?(x)"],
      provider: "istanbul",
      reporter: ["html", "json-summary"],
      reportsDirectory: "./test-results/int/coverage"
    }
  }
});

Result:

Previously, those with 100% branch coverage had 100% coverage for other columns too.

[AriPerkkio]

Can Vitest instrument ts-node subprocesses spawned by spawn or exec?

Currently Vitest does not intercept require() calls that ts-node hooks into. It should be possible to implement a require hook for Istanbul instrumentation so that code that is not run through vite-node could be included in code coverage.

But I'm not sure if it can "see" processes launched by child_process.spawn. There's nothing about patching child_process here: https://github.com/istanbuljs/istanbuljs/blob/fb8cb4bb99c9e5d36c8b011338d2ab5d3c72ff9c/packages/istanbul-lib-hook/lib/hook.js#L229-L236
Could you provide small example of this so that I could test it?

[AriPerkkio]

Currently there are no plans or on-going work to support intercepting require and child_process.spawn. But this doesn't mean that they couldn't be supported in future. There have also been other users requesting support for intercepting require so that files transpiled by ts-node could be included in coverage. Using ts-node seems popular in backend frameworks, e.g. Fastify and Eggjs.

Supporting require seems straightforward but child_process.spawn would be more difficult.

[...] what can I do moving forward?

As you are testing a CLI application, maybe you could start the testing from a different module and not the CLI entrypoint?

- spawnSync("ts-node-esm", [path.join(__dirname, "application.ts")]);
+ await import("application.ts") // Now vite-node will handle the transforms and include it in coverage

It really depends on the application code whether this is possible. But for now that's all that I can think of.

[kirinnee]

Hello, thank you for the answer.

Yes, I am testing a CLI application directly.

I believe outside of spawing, this can work with enough mocking:

• environment mocking
• file descriptor mocking (perhaps mocking console?)
• argv mocking

I have looked around in vitest's mocking system, I am not sure if there are possible, can you point me towards them if they are?

The stub.stubEnv seems confusing, I am not what is the lifecycle (does it auto clean up?)

Is there be a way to mock native console easily?

Lastly, I would like to ask if I should create this as a feature request in GitHub's issue

Thank you!

[AriPerkkio]

Lastly, I would like to ask if I should create this as a feature request in GitHub's issue

Sure, feel free to create issue for this. Then more people will easier find it and tell if they need it as well.

I'm not sure how to answer to these other questions related to console mocking and stubEnv usage without seeing some code examples. I would advise to create separate questions for these in the discussion area here.

[DenizUgur]

@AriPerkkio did you end up create a issue for this? I've stumbled into this while trying to get coverage for web workers and would like to follow the discussion if there's any.

[AriPerkkio]

No, I don't think anyone ended up filing feature requests for this.