Sponsor Link
環境&対象
- macOS Big Sur 11.3 beta
- Xcode 12.4
- iOS 14.4
@testable import
通常の struct や class のメソッドは、public としては定義されていません。
ですので、UnitTest でメソッドを対象にしようとすると (原理的には) public にして外部からアクセスできるようにしなければいけません。
ですが、テストのために メソッドを public にしてしまうと、public な API と勘違いされて使われてしまうかもしれませんので、避けたいところです。
そこで、テスト向けに特別な宣言ができるようになっています。それが、”@testable import” です。
@testable と付与して import することで、アクセスレベルを変更して参照することができます。
@testable 指定したモジュールの internal までのアクセスレベルを参照できるようになります。fileprivate/private は、アクセスできないままです。
この @testable は、非常に便利です。
しかし @testable import 指定すると、たまに “No such module XXXX” となることがあります。
以下では、このエラー解消のためのチェックポイントを説明します。
テストコードは、アプリのビルドが通ることが前提
当たり前っぽいですが、テストコードはアプリのビルドが通っている状態でないと正しく動きません。シンボル等の情報も参照できないと思いますので、コンパイルが通らないことも多いです。
まずは、アプリのビルドがエラーなく終了していることを確認しましょう。
@testable import の対象となるモジュールとは?
アプリをビルドする TARGETS を選択し、”Build Settings” – “Packaging” – “Product Module Name” で確認することができます。
デフォルトでは、プロジェクト名ですが、開発途中でアプリ名称を変更していると、名称変更に伴いモジュール名も変更されていることがあります。
@testable import が “No such module” というエラーになる
以下のような点をチェックすると、大抵(?) 解消できます。
- アプリのビルドが通るかを確認
- @testable import で対象としているモジュール名が正しいか確認
- UnitTest の TARGET 設定で “General” – “Testing” で Host Application が正しく設定されているかを確認
- UnitTest の TARGET 設定で “General” – “Testing” で “Allow testing Host Application APIs” にチェックが入っていることを確認
- アプリの TARGET 設定で “Build Settings” – “Build Options” – “Enable Testabiligy” に Debug : YES となっていることを確認
説明は以上です。
不明な点やおかしな点ありましたら、こちらまで。
Sponsor Link