Swift test fails on cli on new project

Development Swift Testing
1

swift test fails on a new command line project without any changes. I did the following steps:

$ mkdir swift_testing
$ cd swift_testing
$ swift package init --name TestingDemo --type executable
$ swift test

Expectation:

The created tests run and show test failures or success on the command line.

Observation:

The following cryptic errors are printed:

Building for debugging...
error: emit-module command failed with exit code 1 (use -v to see invocation)
/Users/dom/Documents/ablage/swift_testing/Tests/TestingDemoTests/TestingDemoTests.swift:1:8: error: module 'Testing' is in package 'swift_testing' but was built from a non-package interface; modules of the same package can only be loaded if built from source or package interface: /Applications/Xcode-26.4.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/Testing.framework/Modules/Testing.swiftmodule/arm64-apple-macos.swiftinterface
1 | import Testing
  |        `- error: module 'Testing' is in package 'swift_testing' but was built from a non-package interface; modules of the same package can only be loaded if built from source or package interface: /Applications/Xcode-26.4.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/Testing.framework/Modules/Testing.swiftmodule/arm64-apple-macos.swiftinterface
2 | @testable import TestingDemo
3 | 

/Users/dom/Documents/ablage/swift_testing/Tests/TestingDemoTests/TestingDemoTests.swift:1:8: warning: module 'Testing' is in package 'swift_testing' but was loaded from SDK; modules of the same package should be built locally from source only: /Applications/Xcode-26.4.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/Testing.framework/Modules/Testing.swiftmodule/arm64-apple-macos.swiftinterface
1 | import Testing
  |        `- warning: module 'Testing' is in package 'swift_testing' but was loaded from SDK; modules of the same package should be built locally from source only: /Applications/Xcode-26.4.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/Testing.framework/Modules/Testing.swiftmodule/arm64-apple-macos.swiftinterface
2 | @testable import TestingDemo
3 | 
/Users/dom/Documents/ablage/swift_testing/Tests/TestingDemoTests/TestingDemoTests.swift:1:8: error: module 'Testing' is in package 'swift_testing' but was built from a non-package interface; modules of the same package can only be loaded if built from source or package interface: /Applications/Xcode-26.4.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/Testing.framework/Modules/Testing.swiftmodule/arm64-apple-macos.swiftinterface
1 | import Testing
  |        `- error: module 'Testing' is in package 'swift_testing' but was built from a non-package interface; modules of the same package can only be loaded if built from source or package interface: /Applications/Xcode-26.4.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/Testing.framework/Modules/Testing.swiftmodule/arm64-apple-macos.swiftinterface
2 | @testable import TestingDemo
3 | 

/Users/dom/Documents/ablage/swift_testing/Tests/TestingDemoTests/TestingDemoTests.swift:1:8: warning: module 'Testing' is in package 'swift_testing' but was loaded from SDK; modules of the same package should be built locally from source only: /Applications/Xcode-26.4.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/Testing.framework/Modules/Testing.swiftmodule/arm64-apple-macos.swiftinterface
1 | import Testing
  |        `- warning: module 'Testing' is in package 'swift_testing' but was loaded from SDK; modules of the same package should be built locally from source only: /Applications/Xcode-26.4.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/Testing.framework/Modules/Testing.swiftmodule/arm64-apple-macos.swiftinterface
2 | @testable import TestingDemo
3 | 

error: fatalError

Am I wrong to expect that a template project should be able to run its tests? How can I fix that?

2

This peculiar error is a coincidence due to the specific name you chose to give your example package. The copy of Swift Testing included in Xcode uses the package name (literally) swift_testing, and that matches the name of your package. Since those names match, when building your package it produces an error when it attempts to build the test target: it has import Testing and that causes the compiler to evaluate the Testing module as though it were part of your own package (which it isn’t), but it does so via Xcode’s textual .swiftinterface and that scenario is expected to fail.

So the simple resolution is to choose a different name for your package.

2 Likes
3

My bad. Thank you!

4

Would it be possible to keep a list of “reserved” package names that SwiftPM might warn about when creating a new package?

I suspect OP isn’t the only person who got bitten by this coincidence.

5

And it's not the first time I got bitten by strange compiler magic.

6

IIRC (I might be wrong, please correct me if so), the package name just comes from the public name of the package in the manifest, with identifier-unsafe characters converted to underscores: swift-testing/Package.swift at main · swiftlang/swift-testing · GitHub

But the -package-name flag isn't limited to identifier-safe characters, so it would be nice if we could do better here, like using the full package URL or something like reverse domain name form (e.g., com.apple.swift-testing) that's less likely to intersect with something a user might write. But that would require some changes in SwiftPM, at a minimum.

But I do think the bigger problem ultimately is the lossy conversion to an identifier. It's somewhat reasonable that if someone created their own package named swift-testing, they'd understand why the real swift-testing causes problems when used at the same time. But swift-testing and swift_testing look different enough that it's confusing. And what's worse, this is happening even when swift-testing isn't used as a package dependency, because the -package-name used during compilation is baked into the .swiftinterface files that the compiler emits and are stored in the Xcode SDKs.

Maybe Apple would be willing to substitute a different -package-name for swift-testing when they build their SDK releases?

1 Like
7

We do, actually. The whole point of using -package-name in Swift Testing is to allow you to swap out the copy in Xcode with a locally-built copy.

8

I guess this is ultimately another unfortunate decision that Swift has repeatedly made, like with modules: load-bearing names taken from a single-level namespace, making collisions tricky (and sometimes impossible) to deal with.

9

Somehow the issue reminds me of SR-10314, which indicates we can't have a package named "Network" with a library named "SwiftNetwork" in the package.