Using @_exported together with @testable

Using Swift
, ,
1

Hi :wave:

I found myself re-architecturing a project, and I have to split the test module in two: TestModuleA and TestModuleB, where TestModuleA depends on TestModuleB.

Since this is not production code, I thought I could avoid many source code changes by doing the following from inside TestModuleA:

@_exported @testable import TestModuleB

But seems like the @testable is not considered when using @_exported, which forces me to make big source code changes: not use @_exported and instead add @testable import TestModuleB in almost all files of TestModuleA.

Is there any other alternative? Is there a way to make @_exported @testable import TestModuleB work as expected? Maybe by passing custom build settings to the complier?

Thanks :pray:

1 Like
2

@testable exposes internal interface of the imported module to the importing module. Why would you want access to TestModuleB? I assume it would contain tests only and any utility functions/classes would be separated into yet another Utilities module.

Also for @testable to work you'd have to compile the imported module with testing enabled (quote from Swift book):

<...> a unit test target can access any internal entity, if you mark the import declaration for a product module with the @testable attribute and compile that product module with testing enabled.

3

@testable exposes internal interface of the imported module to the importing module.

Yes.

Why would you want access to TestModuleB ? I assume it would contain tests only and any utility functions/classes would be separated into yet another Utilities module.

TestModuleB is what you call Utilities: it contains utilities I need in TestModuleA and in other modules.

Also for @testable to work you'd have to compile the imported module with testing enabled (quote from Swift book):

Yes. Testing is enabled by default in all DEBUG targets when using Xcode.

1 Like
4

Would it make sense for you to make those utilities public then? Or better yet - extract them into TestUtilities module?

I understand that I am not answering your question, but I wonder if this approach would make sense to you too :slight_smile:

5

Would it make sense for you to make those utilities public then? Or better yet - extract them into TestUtilities module?

Nope, as the utilities include extensions to internal classes declared inside the main module. Ill give you an example:

In main module:

struct MyStruct {}

In TestModuleB:

@testable import Main

extension MyStruct {
    static func sample() -> MyStruct { ... }
}

I understand that I am not answering your question, but I wonder if this approach would make sense to you too :slight_smile:

Thanks for the answers :pray: I am aware that there is a way around it: add @testable import TestModuleB in every file of TestModuleA. But I would like to avoid it, that is why I am asking about the possibility of using @_exported @testable import TestModuleB

1 Like