Generated test plans discard TestAction coverage and environment options

Metadata

Source

tuist/tuist #12299

Updated

Aug 12, 2026

Domains

Generated projects Testing

Details

What happened?

When a scheme switches from a path-based .xctestplan to a generated test plan, plan-level test settings cannot be represented and are silently absent from the generated file.

In particular, settings already exposed by TestAction, such as options: [.coverage], coverageTargets, expandVariableFromTarget, and environmentVariables, are not written to the generated plan’s defaultOptions or configuration options.

Expected: a generated plan should preserve the effective test configuration, or the API should provide an explicit way to define the corresponding plan-level options instead of silently generating a behaviorally different plan.

How do we reproduce it?

Use Tuist’s official examples/xcode/generated_app_with_generated_test_plan example.
Configure its test action with coverage, an environment variable, and an expansion target, for example:

testAction: .testPlans(
    [
        .generated(
            name: "UnitTests",
            testTargets: [.testableTarget(target: "AppTests")]
        ),
    ],
    options: [.coverage],
    coverageTargets: ["App"],
    expandVariableFromTarget: "App",
    environmentVariables: ["TEST_ENV": "value"]
)

Run tuist generate.
Inspect Derived/TestPlans/UnitTests.xctestplan.
Observe that its defaultOptions and configuration options are empty; coverage, environment, and expansion settings are not represented in the plan.

The generated TestPlan API accepts only the name, test targets, path, and default selection, so there is no plan-level alternative for these fields.

Error log

There is no warning or error. The generated plan silently contains empty option dictionaries:

{
  "configurations": [
    {
      "options": {}
    }
  ],
  "defaultOptions": {}
}

macOS version

26.4.1

Tuist version

4.201.0

Xcode version

27.0 (27A5209h)

Flights

Investigate, reproduce, or fix this item in an isolated repository. Each Flight preserves its outcome and agent session.

New Flights are paused Configure model inference, GitHub, and a sandbox provider to start another Flight. Existing results remain available below.

No Flights yet

Start a Flight and preserve its objective, outcome, and session here.

Comments

D

dosubot[bot] Aug 12, 2026

Hi @Kus-Sl! I’m Dosu and I’m helping the Tuist team.

This is a confirmed gap in the current implementation. Here’s what happens under the hood:

TestPlanDescriptor.encode() hardcodes defaultOptions: [:] and a single configuration with empty options — it never reads coverage, environment variable, or expansion settings from the TestAction.
The TestPlan.generated(...) API only accepts name, testTargets, and an optional path — there are no parameters for plan-level options.
The manifest mapper only carries the path, targets, and kind: .generated into the graph model, so TestAction-level settings like options: [.coverage], coverageTargets, expandVariableFromTarget, and environmentVariables are never forwarded.
TestPlanDescriptor+Extras.swift, which builds the descriptor from the graph, similarly passes nothing about coverage or environment variables into the plan.

The underlying XCTestPlan model already supports arbitrary defaultOptions and per-configuration options as [String: AnyCodable] dictionaries [1], so the plumbing to write these values exists — but nothing populates them for generated plans.

Workaround: There is no way to set these options on a generated plan today. If you need coverage, environment variables, or an expansion target in your test plan, you’ll need to maintain a hand-authored .xctestplan file and reference it via .path(...) instead of .generated(...).

Since fixing this requires a design decision (should TestAction options propagate automatically, or should TestPlan.generated(...) grow explicit parameters?), I’d suggest continuing the discussion on the community forum under the development category where the maintainers can weigh in on the preferred approach.

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.