What's the difference between importing a target into unit testing and including that file among the target Membership?

Question

When I'm writing tests I can do:

@testable import TestProduct

How is the above different from adding the Test File to a specific Target?

Ultimately my question is: Had I made my unitTests a target to all my files...would it be equivalent to doing:

@testable import TestProduct

If not, then what is the difference?

Answer 1

From the Swift docs under the heading Access Levels for Unit Test Targets (emphasis added)

When you write an app with a unit test target, the code in your app needs to be made available to that module in order to be tested. By default, only entities marked as open or public are accessible to other modules. However, 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.

These docs say that the @testable attribute provides your Unit Test target access to all internals of the module marked as @testable. Thus letting you avoid having to manually add individual files in that module to the Unit Test target.

The @testable import is typically done on large codebases that did not have any tests yet... because this approach is significantly slower than adding the files you want to test to the test target.

Answer 2

Honey. @testable import YourAppModuleName exist in your tests - unit testing. This will expose Any public and default symbols to your tests. private symbols are still unavailable. This is in build settings.

Create a new file in the test target and name it to something like MyFirstSpec.swift. Put this content into it. OR Create a framework target. If you’re not a big fan of duplicating files, you can create a framework target that includes the source files you’re looking to test. Also, you can refer this on github for automation: https://github.com/johnsundell/playground