When test support code relies on production code, a diamond can occur. If this occurs across packages, it can lead to duplicated symbols and incorrect behavior at runtime despite no warnings at build time. This only occurs in Xcode and top-level application testing. This doesn't occur when the code being tested is in a separate package.
I'm trying to understand how to correctly manage shared test support code which needs to access production code, or if this is the correct way and it is an Xcode bug.
For a minimized example project, see https://github.com/rnapier/SupportCode.
The setup includes three packages: Dependencies, which manages all the dependencies for the app and tests; Core which contains core logic and test support; and Feature, which relies on Core an contains feature-related logic and test support.
Building this system causes Core.framework to show up three times in DerivedData:
./App.app/PlugIns/AppTests.xctest/Frameworks/Core_59974D35D_PackageProduct.framework
./App.app/Frameworks/Core_59974D35D_PackageProduct.framework
./PackageFrameworks/Core_59974D35D_PackageProduct.framework
When unit tests are run, there is a collision on the symbol for Keychain:
objc[48914]: Class _TtC8Keychain8Keychain is implemented in both /Users/ornapier/Library/Developer/Xcode/DerivedData/App-grdjljgevqofhqgflgtrqvhvbtej/Build/Products/Debug-iphonesimulator/PackageFrameworks/Core_59974D35D_PackageProduct.framework/Core_59974D35D_PackageProduct (0x100a98118) and /Users/ornapier/Library/Developer/CoreSimulator/Devices/216C441E-4AE5-45EC-8E52-FA42D8562365/data/Containers/Bundle/Application/7197F2F2-EB26-42FF-B7DB-67116159897D/App.app/PlugIns/AppTests.xctest/AppTests (0x1011002c0). One of the two will be used. Which one is undefined.
This is not a benign warning. There are two distinct copies of _TtC8Keychain8Keychain and test cases will access one and the app will access a different one. This leads to mismatches when accessing static instances such as .shared.
I believe this dependency graph should work, and it does work as long as the top-level testing system is a Swift module. But if it is the application, it builds successfully, but behaves incorrectly in subtle ways.