Hive
XCTest-dependent helper targets (TestSupport, test utilities) should be cacheable
GitHub issue · Open
Why is this needed?
staticFramework targets that depend on XCTest (e.g. TestSupport targets providing test mocks/helpers) are excluded from binary caching. These are not test bundles — they’re regular frameworks only consumed by test targets.
tuist cache --print-hashes does not list any XCTest-dependent staticFramework target. In our project this excludes ~60 targets (TestSupport modules, SnapshotTesting, test utility frameworks) — none of which are dependencies of the app target.
Reproduction:
- Create a
staticFrameworktarget that depends on an SPM package importing XCTest - Run
tuist cache --print-hashes - The target does not appear in the cacheable list
Environment: Tuist 4.150.0 (Cloud/EE), Xcode 26.2, macOS 26.2
Steps to address the need
Non-test-bundle targets (staticFramework, framework) that depend on XCTest should be included in tuist cache --print-hashes and be cacheable as xcframeworks. Replacing a TestSupport target with a binary doesn’t change the dependency graph — it’s still only consumed by test bundles.
Investigate, reproduce, or fix this item in an isolated repository. Each Flight preserves its outcome and agent session.
Start a Flight and preserve its objective, outcome, and session here.
Hi @eghnacr! I’m Dosu and I’m helping the tuist team.
This is a known limitation in Tuist’s binary caching. The caching logic excludes any target with an XCTest dependency, without distinguishing between actual test bundles (.unitTests, .uiTests) and utility frameworks that happen to import XCTest.
The check happens in dependsOnXCTest(), which returns true if a target:
- Is a test bundle product
- Has
ENABLE_TESTING_SEARCH_PATHSset to “YES” - Has a direct dependency on
XCTest.framework
There was actually a PR #8529 attempting to remove this restriction, but it was closed without merging. The original rationale (from PR #4012) was that XCTest-dependent libraries have “non-deterministic behavior in caching scenarios.”
For a deeper discussion on this feature request, I’d recommend opening a thread on the community forum in the Ideas category, explaining your use case with ~60 affected TestSupport modules. The maintainers may have more context on why PR #8529 was rejected and whether there’s appetite to revisit this.
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.