Tuist cache + selecting testing erroneously skips all tests

Tuist’s selective testing skips tests if no source code changes are detected since the last successful run, regardless of whether the previous test run failed or timed out. This is expected behavior: selective testing only considers file changes, not the outcome of previous test runs, so pushing a non-source code change will not trigger a rerun of failed tests and may incorrectly report them as passed if the cache is still valid. This limitation is confirmed by maintainers and documented in this issue.

Currently, there is no configuration or workaround in Tuist to force rerunning tests after a failed or incomplete run when using selective testing. The cache invalidation logic does not track test outcomes—only content hashes—so transient failures like timeouts are not accounted for in subsequent runs. To ensure tests are rerun after failures, you may need to disable selective testing (--no-selective-testing) or manually invalidate the cache.

Let me know if you want details on disabling selective testing or forcing a full test run.

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

@dosu maybe this is worth a discussion or some added documentation because this feels kind of dangerous from a CI standpoint if we are relying on the tuist cache to tell us if tests pass. Particularly in a scenario like:

1. I push a PR that doesn’t compile because i wrote Sting instead if String in one module, but I’ve made changes in 3 modules. Tests fail because they don’t compile.
2. I push a fix for that one module, but only that module’s tests get run because that’s the only change seen, but there could be errors in the other 2 caught by unit tests.

You’re right—this is a real risk with Tuist’s selective testing and caching in CI. Selective testing currently skips tests for modules that haven’t changed since the last successful run, regardless of whether previous runs failed or didn’t compile, which can lead to missed errors in other modules if only a subset of changes are detected. This limitation is acknowledged by maintainers and is being actively discussed for improvement and documentation [source].

Recent work has started to address this by caching successful test results even if other tests fail, but the granularity is still at the module/target level, not at the file or test case level [source]. There are also proposals to add CLI flags (like --no-upload) and configuration options to control when selective test results are uploaded to remote cache, which could help mitigate CI risks [source].

For now, best practices to avoid false positives in CI include disabling selective testing (--no-selective-testing) for critical runs, manually invalidating the cache after failed builds, or configuring cache profiles to force full test runs when needed. This area is definitely worth further documentation and discussion, and the community is aware of the need for clearer guidance and safer defaults [source].

To reply, just mention @dosu.

Docs are dead. Just use Dosu.