私は時間をかけていくつかの単体テストをセットアップし、XCode などでターゲットをセットアップしましたが、それらはいくつかのクラスで非常に役立ちます。でも：
アプリケーション全体を起動したくない小さな UI 部分をテストしたい。合格/不合格の概念はありません。ピースを「見る」必要があり、これを行うために関連するすべてのクラスのダミー インスタンスを作成できます。私の質問は、XCode でこれを設定するにはどうすればよいですか?
各クラス (またはクラスのグループ) ごとに別の XCode プロジェクトを使用できることはわかっていますが、それは少し面倒です。それぞれの別のターゲット？
完全に機能するアプリケーションを必要としない UI コンポーネントをテストするためのアプローチを探していることは承知していますが、iOS 4.0 で導入された新しい UI オートメーション インストルメントが実現できることに感銘を受けました。
この計測器を使用すると、Javascript スクリプトを使用して、アプリケーションのインターフェイスをインタラクティブにテストできます。これは、正確なピクセル値や画面上の位置を確認する必要がない方法で行います。VoiceOver のシステムに存在する組み込みのアクセシビリティ フックを使用して、コンポーネントを識別して操作します。
このツールを使用して、ユーザーがアプリケーションを操作するときにアプリケーションを完全に実行するテストや、特定の領域を叩いて微妙なメモリの蓄積を探すテストをスクリプト化することができました。
Instruments のこの部分に関するドキュメントは少し少ないですが、私は最近、iTunes Uで無料でビデオを利用できる主題をカバーするクラスを教えました (秋学期のテストクラスを探してください)。私のコース ノート(VoodooPad 形式) もこれをカバーしています。また、 WWDC 2010 ビデオセッション 306 - 「計測器を使用したユーザー インターフェイス テストの自動化」を視聴することを強くお勧めします。
GUI が大規模なアプリケーションの一部であっても、GUI の一部を表示することをテストと呼ぶことはできません。ここでできることは、個別の実行可能ターゲットを作成し、アプリケーションから GUI コンポーネントを再利用して入力パラメーターに基づいて表示する小さなツールを作成することです。これにより、多くの異なるターゲットの必要性がなくなります。
それでも単体テストの使用を主張する場合は、GUI を一定時間 (たとえば 10 秒間) 表示することができます。したがって、テスト ケースは GUI が閉じられるかタイムアウトが経過するまで実行され、各テストの実行には最大 N 秒かかります。
これは良い質問です。実際には、これらの「視覚的な確認」に単体テストを使用したくないと思います。個人的には、この種のテストや開発を行うために、通常は小さなテスト アプリを作成します。私は同じプロジェクト内に別々のターゲットがあるのは好きではないので、通常は元のプロジェクトの隣にテスト プロジェクトを作成し、相対パスを使用してそれらのクラスとリソースを参照します。混乱が少ない。また、より複雑なユーザー インターフェース要素を独自の小さなテスト環境でテストできることは本当に素晴らしいことです。
UI の「単体テスト」には、次の 2 つのレベルのアプローチを採用します。
Cocoa/CocoaTouch は Model-View-ViewModel パラダイムよりも Model-View-Controller に近いものですが、「ビュー」を「ビュー モデル」と「プレゼンター」ビューに分割することで、テスト容易性の利点の多くを得ることができます (これは NSView/NSCell のペアに多少似ていることに注意してください (Cocoa のエンジニアはずっと前にこれを使用していました)。ビューが単純なプレゼンテーション レイヤーの場合は、「ビュー モデル」の単体テストによってビューの動作をテストできます。
ビューの描画/レンダリングをテストするには、人間によるテストを行うか、レンダリング/ピクセル ベースのテストを行う必要があります。Google の Mac 用ツールボックスには、レンダリングされた NSView、CALayers、UIView などをピクセル単位で比較するためのツールがいくつかあります。コア プロット プロジェクト用のツールを作成して、テストの失敗に対処し、参照ファイルをマージして元に戻します。単体テスト バンドルを少し簡単にします。