`DependenciesTestSupport` from `swift-dependencies` does not build

Troubleshooting & how to
1

Question or problem

Using the swift-dependencies package (which is included transitively from TCA), when adding a dependency on the DependenciesTestSupport product to a test target, there’s a build failure.
The build failure is in the IssueReportingTestSupport library in the xctest-dynamic-overlay package, which is a dependency of DependenciesTestSupport.
It’s in the file XCTest.swift.

This file adds functionality for when XCTest is available, and there’s a check at the top of the file #if canImport(XCTest), which appears to succeed as the following code is not greyed out.

However, the code in canImport attempts to access XCTest functions like XCTFail and cannot find them. This is the build failure.

Looking at the IssueReportingTestSupport target, it doesn’t have XCTest as a dependency. Adding it appears to resolve the build failure.

Now I’m using Swift Testing and Swift 6, and since XCTest isn’t a dependency of IssueReportingTestSupport, I wouldn’t even expect #if canImport(XCTest) to succeed and attempt to access XCTest functions.

So I’m not sure what I expect here. If canImport(XCTest) could fail somehow, then Tuist’s behavior of not linking against XCTest would be correct.

Expectation

Adding DependenciesTestSupport as a test dependency should build fine.

Context

  • Tuist version: 4.37.0

Reproduction (mandatory for problems)

Add the swift-dependencies package to a project
Create a target with a test target
Add DependenciesTestSupport as a dependency of the test target
Create a test with Swift Testing, import DependenciesTestSupport and try to run it
Building the test target fails

2

Hey @adarhef :slightly_smiling_face:

Can you try setting the ENABLE_TESTING_SEARCH_PATHS setting to YES for the IssueReportingTestSupport library in the PackageSettings.targetSettings?

Unfortunately, we don’t know by what magic Xcode knows if a target depends on XCTest when that’s not explicitly declared in the Package.swift. Because of that, we have a hardcoded map of known testing targets for which we add the above setting by default: PackageSettings · Project Description · References · Tuist.

Ideally, we’d figure out automatically if that setting value needs to be set, but that’s easier than it sounds.

1 Like
3

Thanks @marekfort !
That did the trick. I wasn’t aware of this setting.

I do wonder though, why does canImport(XCTest) succeed regardless of whether it can be imported?

The library does attempt to protect against instances where XCTest isn’t available and it just doesn’t appear to be doing anything.

4

Nice! Would you be up to open a PR and add the dependency to the list of testing dependencies?

I’m not 100 % sure. You can go to the build logs and see the actual flags being passed to the dependency when compiling.

5

Sure thing. Looked around at where the relevant hardcoded list was and I think I found it, opened a PR:

Set ENABLE_TESTING_SEARCH_PATHS for IssueReportingTestSupport by adarhef · Pull Request #7188 · tuist/tuist · GitHub]

1 Like
6

@marekfort So after adding the testing search paths, the tests do finally run. However, they fail.

I looked into it and using a fresh Tuist project, they also fail. But they succeed on a simple project without Tuist.

This fails:
DependenciesTestSupportWithTCATuist.zip (58.5 KB)

This succeeds:
DependenciesTestSupportWithTCA.zip (35.6 KB)

I know this is perhaps unrelated but who knows…

7

Hey @adarhef!

That looks like an issue in how we integrate these packages. Would you mind raising an issue and providing some extra details for the behavior you’re seeing vs. behavior you’d expect?

8

Done:

1 Like