Support jest cli options when using @angular-devkit/build-angular:jest

[rafagsiqueira]

Command

test

Description

Sometimes it might be necessary to provide cli options to jest that are decided at "runtime".
Example below of a debug configuration for running tests in vscode:

{
  "configurations": [
    {
      "type": "node",
      "name": "vscode-jest-tests.v2",
      "request": "launch",
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "ng",
      "args": [
        "test",
        "etips-utils",
        "--run-in-band",
        "--watch-all=false",
        "--test-name-pattern",
        "${jest.testNamePattern}",
        "--test-path-pattern",
        "${jest.testFile}"
      ]
    }
  ]
}

Describe the solution you'd like

The project https://github.com/just-jeb/angular-builders implements an approach to allowing jest cli options.
https://github.com/just-jeb/angular-builders/blob/8f00fd9b324d0151f722a4e962fcbeab7891baae/packages/jest/src/index.ts#L37C11-L37C11

Describe alternatives you've considered

Alternative is to use https://github.com/just-jeb/angular-builders, but the build requires a lot more configuration to work with angular and esm.

[hannry45]

Thank you for sharing the example and the link to the project. I will consider using the https://github.com/just-jeb/angular-builders project as an alternative. However, I am concerned about the additional configuration required for it to work with Angular and ESM.

Best regard,
MyTHDHR

[johncrim]

I could create a separate issue for "Support debugging jest tests", but I think it's covered by this issue.

Today we use the following VS Code launch configuration to debug the current jest test file:

    {
      "name": "Jest current file",
      "type": "node",
      "request": "launch",
      "runtimeArgs": [
        "--experimental-vm-modules",
        "--inspect-brk",
        "${workspaceRoot}/node_modules/jest/bin/jest.js",
        "/${fileBasenameNoExtension}",
        "--watch",
        "--runInBand",
        "--testTimeout=10000000" // Prevent timeouts when running in debugger.
        //,"--no-cache"
      ],
      "console": "integratedTerminal",
      "internalConsoleOptions": "neverOpen",
      "env": {
        "TEST_ENV": "debug",
      }
    },

I think it's pretty critical to support such a use-case with the Jest builder. There's a case to be made for abstracting this operation into the builder - lmk if you want a separate issue for this.

[rafagsiqueira]

Thank you for looking into this. The debugging configurations do work, the problem is when extensions are used which rely on adding runtime parameters to jest. A simple example would be running a single test on a rather long test file. I don’t see how that could be done except adding it.skip to all the other tests on the current file. Extensions dynamically add filters by test name, when tests are ran from the context menu, for example.

[johncrim]

@rafagsiqueira - to run a single test, try replacing it => fit or it.only.

But that doesn't discredit this issue, I think there are a lot of use-cases for inserting jest arguments when running tests.

[dgp1130]

Allowing Jest CLI options to pass through ng test is a similarly scoped problem to allowing a custom Jest configuration. It's a lot harder for the CLI to intelligently wrap the underlying Jest infrastructure when we understand the semantics of what's actually being executed. Passing custom flags breaks that as we lose knowledge of what Jest is trying to do under the hood.

As for debugging, that's definitely a use case we'll need to support. I have some early ideas about a --debug flag which would set --run-in-band (and maybe --inspect-brk?) as well as supporting test filters. I think it will be better to support that use case directly rather than asking users to learn about all the relevant Jest flags and which ones they need to use for the behavior they want.

Duplicate of #25434

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}