Configure which tests runs in a new process

[johlju]

When testing DSC class-based resources we need to run the tests in a separate session to be able to re-run the tests after changes to the code (otherwise the class is already loaded into the session with old code). In command line I normally start the tests in a separate job.

For the Pester Test Adapter I can set the setting pester.runTestsInNewProcess to true. But this will make all tests run in a new process. That makes running tests for the other code (that do not use classes) much slower than it needs to be.

I suggest adding a new setting pathsToRunInNewProcess (we can come up with better naming), and any test script file that are part of those paths will run in a new process while the others run in the same process (the default way).

{
    "pester.pathsToRunInNewProcess": [
        "[tT]ests/[uU]nit/Classes/*.[tT]ests.[pP][sS]1"
    ]
}

[JustinGrote]

While this can potentially be done it would be really difficult to correlate the tests together because now I have two different pester "runs" and it would require a lot of code to stitch all those results together, identify duplicates, what do we do with the duplicates, etc..

Why can't you just start a new PowerShell Process within your pester test for this and parse the output? That's usually what I do when testing assemblies.

[johlju]

In the end I rather take slowness over test code complexity.... 🙂

Why can't you just start a new PowerShell Process within your pester test for this and parse the output? That's usually what I do when testing assemblies.

Do you have an example on how you start a job inside the pester test?

I can see that it would be doable but I think it would also come with some non-preferred result.

• Would make tests even more complex to write for contributors, it’s already difficult for most contributors to write them.
• How the (our) pipeline works (testing built module) we would need to set up the pipeline in the job (run build.ps1 -Task noop) for each test script for it to be able to test the built module, it could be done, but this would take time when running the tests. In command line we only need to do this once before running Invoke-Pester in the new job.
• We don’t need need run the tests in a job when running the tests in the CI. The job could potentially be skipped if detected to run in CI, but then we are back to number 1, complex tests.

...identify duplicates, what do we do with the duplicates, etc..

Could we make sure that the same test file is not run twice so this isn't a problem, throw if user cofigures it in a way that the same test script file tries to run twice? That way we "just" have to combine each array from a Pester run.

[JustinGrote]

@johlju now that multi-root workspace is functional, you should be able to do the following to achieve your goal:

1. Make separate folders for your "reuse process" and "new process" tests.
2. For the "new process" tests, add a workspace setting for that particular folder for the Run Tests in New Process setting.
3. Tests that fall under that test runner will now run in a new process each time.

Theoretically there could be some way to work on tags to filter tests into different categories of runtime, but that's more complicated than I'm willing to implement (especially since Pester itself doesnt do this), this is a sufficient solution.

Closing as Not Planned for the more detailed stuff, recommending the workaround above.