Add Test Isolation support

[Drakonian]

Add Test Isolation support

Why

BC runtime 16 (2025 W2) added the RequiredTestIsolation property on test codeunits. The standard BC test runner has a single, fixed TestIsolation value, so any project that mixes codeunits with different isolation requirements cannot run them all under one runner, those tests get excluded from CI.

AL-Go today makes one blanket Run-TestsInBcContainer call per test app under the default runner. Test codeunits that need a non-default runner (e.g. TestIsolation = Disabled for long-running integration tests that must not roll back) have to be placed in disabledtests.json and run manually, losing CI coverage.

This contribution closes that gap.

Discussion reference

#1565

How

A new opt-in testIsolation setting lets projects partition the test stage:

"testIsolation": {
  "enabled": true,
  "defaultRunnerCodeunitId": 0,
  "partitions": [
    { "runnerCodeunitId": 130451, "codeunits": "99209" }
  ]
}

When enabled, RunPipeline installs a -RunTestsInBcContainer scriptblock into Run-AlPipeline that, per test app:

1. Invokes Run-TestsInBcContainer once per entry in partitions, with -testRunnerCodeunitId and -testCodeunitRange set from the entry.
2. Issues one trailing call under defaultRunnerCodeunitId whose -testCodeunitRange is the negation of every explicit partition's filter, so codeunits not in any partition run exactly once under the default runner.

The scriptblock forwards all other Run-AlPipeline parameters verbatim, so disabledTests.json handling, JUnit result appending, container lifecycle, and useCompilerFolder support continue to work unchanged. Feature is strictly additive and off by default.

Validation

• Pester suite passes locally and in CI.
• End-to-end on a real BC 27 project (parallel-worker-bc, green): 33 integration tests that had been permanently disabled via disabledtests.json for lack of a TestIsolation = Disabled runner now execute successfully under standard BCApps runner 130451, while the remaining test codeunits (99201–99203) run under the default runner in the same build — proving both the partition call and the negated-filter fallback work against real BcContainerHelper.

[Copilot]

Pull request overview

Adds opt-in “test isolation” support to AL-Go so a single test stage can be partitioned across multiple test runners (to satisfy mixed RequiredTestIsolation requirements) while preserving existing Run-AlPipeline behaviors like disabled tests handling and result aggregation.

Changes:

• Introduces new testIsolation setting (defaults, schema validation, and documentation).
• Adds a RunTestsInBcContainer override hook in RunPipeline that runs partitions + a default “everything else” pass.
• Adds Pester coverage for the new partitioning scriptblock and settings schema shape/validation.

Reviewed changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
Tests/TestIsolation.Test.ps1	New Pester tests covering partition invocation behavior, negated default filter construction, parameter forwarding, and failure aggregation.
Tests/ReadSettings.Test.ps1	Extends schema tests to cover testIsolation defaults and schema validation rules.
Scenarios/settings.md	Documents the new testIsolation setting in the settings reference table.
Scenarios/TestIsolation.md	Adds a dedicated scenario doc describing configuration, semantics, compatibility, and edge cases.
RELEASENOTES.md	Adds release notes entry describing the new opt-in test isolation partitioning capability.
README.md	Links the new Test Isolation scenario from the main scenarios list.
Actions/RunPipeline/RunPipeline.ps1	Wires testIsolation into Run-AlPipeline by injecting a partitioning RunTestsInBcContainer scriptblock and emitting telemetry.
Actions/.Modules/settings.schema.json	Adds testIsolation schema (object shape, required keys, and partition entry validation).
Actions/.Modules/TestIsolation.psm1	New module that builds the partitioning scriptblock and computes the negated default codeunit-range filter.
Actions/.Modules/ReadSettings.psm1	Adds testIsolation to default settings so it participates in the normal settings merge+validation pipeline.

[mazhelez]

What if there already is RunTestsInBcContainer override for other purposes?
Is there a way to add test isolation w/o using RunTestsInBcContainer?

[Drakonian]

@mazhelez

Great questions!

1. I can combine the user scriptblock with the new hashtable testCodeunitRange + testRunnerCodeunitId. In that case, nothing will be overwritten.

2. In the current design of bccontainerhelper, I see an alternative, in recent versions, RequiredTestIsolation was added, and it looks like this can be used as an alternative.

https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/properties/devenv-requiredtestisolation-property

https://github.com/microsoft/navcontainerhelper/blob/c5fd2aa4e7a36405e50d552a3947102a05931003/AppHandling/Run-TestsInNavContainer.ps1#L532

I think I should look into point 2, I will try testing it and let you know if it works or not.

[Drakonian]

@mazhelez the main problem with RequiredTestIsolation that it will work only for Runtime 16.0 +