問題タブ [ocmock]

iOS 4 プロジェクトに OCMock を追加しようとしています。それをテストするために、Person1 つのメソッドを持つクラスがあり-helloます。このテストを実行すると:

すべて問題なく、ビルドは成功します。次のhelloように電話を切ると：

期待したメソッドがモックで呼び出されなかったことを知らせるエラー メッセージが表示されることを期待しています。代わりに、テスト リグのクラッシュに関する不可解なメッセージが表示されます。

予想されるメソッドが呼び出されない場合、このクラッシュは正常ですか? 設定が悪いのでしょうか?

私は自分のプロジェクトに単体テストを追加し、テスト駆動型の方法で開発を続けることにしました。現在、ManageSieveクライアントオブジェクトの単体テストの実装に取り​​組んでいますが、その獣をテストするための最良の方法がわかりません。

私SieveClientのオブジェクトは、ネットワーク通信のために他の2つのオブジェクトに依存しています。1つは、認証メソッドを処理するためのCyrusSASLライブラリのラッパーであるCocoaAsyncSocket自分のオブジェクトです。SaslConnテストのために、それらをモックオブジェクトに置き換える必要があります。これにはOCMockフレームワークを使用します。SieveClientオブジェクトはそれらのオブジェクト自体を作成する必要があるため、これを行う方法はよくわかりません。現在、そのオブジェクトの（プライベート）セッターを上書きして、常にOCMockspartialMockForObject:メソッドを使用してモックオブジェクトをインストールしています。しかし、これは私には正しくないと感じています。これをよりよく解決する方法はありますか？

私が問題を抱えている他の部分は、ソケット自体です。プロトコルの詳細をテストできるようにするには、ソケットから事前定義されたテストデータを返す方法が必要です。OCMockメカニズムを使用して、ソケットからの戻り値を偽造することができると思います。しかしCocoaAsyncSocket、ソケットからデータを読み取るためのさまざまなメソッドが提供されているため、プロトコルオブジェクトによってどの順序で使用されているかを正確に知る必要があります。単体テストをプロトコルオブジェクトの実装の詳細に依存させたくありません。だから私はここで何をすべきですか？ソケットクラスのモックオブジェクトを手動で実装しますか？これは些細なことではないように思われるので、おそらくそのための単体テストも必要になるでしょう。それはいい考えですか？

何かをテストするのが難しい場合、それもおそらくあまりうまく設計されていないことを私は読んだ。しかし、難しいのは私がしなければならないソケットとの相互作用にあるので、どうすればもっとうまくできるかわかりません。

コードを確認したい場合は、Bitbucket：SieveClient.mおよびSieveClient.hで見つけることができます。

編集：依存性注入

だから私は依存性注入について読みました、そして私はこれを使ってAsyncSocketとSaslConnオブジェクトを私のSieveClientオブジェクトに入れるつもりだと思います。これらのオブジェクトを受け入れて使用するようにコンストラクターを変更します。このクラスのユーザーは通常、ソケットとSASLオブジェクトを気にしないので、これらのオブジェクトを作成してコンストラクターに渡すだけのファクトリメソッド（コンビニエンスコンストラクターの形式）を追加します。

しかし、これは私のテスト問題の最初の（そしてより簡単な）部分だけを解決します。

編集：これはすべて、他のリンクフラグ設定のタイプミスが原因でした。詳細については、以下の私の回答を参照してください。

iOS View Controllerのテスト中にUIWebViewのメソッドが呼び出されていることを確認できるように、UIWebViewをモックしようとしています。私は、SVNリビジョン70（この質問の時点で最新）から構築されたOCMock静的ライブラリと、SVNのGoogle Toolbox for Mac（GTM）ユニットテストフレームワーク、リビジョン410を使用しています。ビューコントローラが期待されるメソッドを呼び出そうとすると、次のエラーが発生します。

私のテストコードは次のとおりです。

私のビューコントローラコードは次のとおりです。

代わりに次を使用すると、テストが正常に実行されることがわかりました。

ただし、コメントアウトされた期待値を追加するとすぐに、部分モックを使用するとエラーが返されました。

同じプロジェクトでモックを正常に使用している他のテストがあります。

何か案は？UIKitオブジェクトのモックはOCMockでサポートされていますか？

編集：以下の回答のアドバイスに基づいて、次のテストを試しましたが、同じエラーが発生します：

OCMock 1.70を使用していますが、BOOL値を返す単純なメソッドのモックに問題があります。これが私のコードです：

私は何が間違っているのですか？

プロジェクトでGHUnitを使用していますが、ユニットテストを完了するにはOCMockについて学ぶ必要があります(ただし、これは初めてです)。私はxcode 3.2.5で作業しています

誰かが OCMock に関する優れたチュートリアルを知っていますか?

ありがとう。

OCMockを使用して模擬UINavigationControllerを作成しました。ただし、UIViewControllerのnavigationControllerプロパティは読み取り専用であるため、このプロパティに割り当てることはできません。

このブログ投稿の作者は、解決策を見つけたと主張していますが、それを共有することを怠っています。

IBoutletコントローラ クラスのすべての が NIB ファイルに正しく接続されていることを単体テストで確認したいと考えています。OCMock を使用してこれを行いたいと思いますがnil、NIB をロードした後ではなく、コントローラーの変数を単純にアサートできることはわかっています。これは、プロセスがどのように機能するかについての一般的な理解の問題です。私が理解している限り、これも機能するはずです。

NIBOnOffSwitchCellには File's Owner がありOnOffSwitchCellControllerます。これは私のテスト方法です：

guiBundle存在し、有効な NSBundle オブジェクトであることが確認されています。

私が理解していることからloadNibNamed:owner:options:、NIB内のオブジェクトを逆シリアル化し、呼び出してから、それぞれawakeAfterUsingCoder:を呼び出してアウトレットを設定しsetValue:forKey:ます。

ロードされた NIB に実際に正しいオブジェクトが含まれていることを確認するために、さらに 3 つのアサートを追加しました。実際のコントローラーのインスタンスを追加すると、これらは OK を通過します。しかし、上記のようにモックを使用すると、ここまで到達しません。代わりに、テストは次のようにクラッシュします。

awakeAfterUsingCoder:そのため、私は明らかに期待していたにもかかわらず、への呼び出しが予期しないものであると不平を言っています。

また、その期待を取り除き、モックを余分なメソッド呼び出しを報告しない素敵なモックに置き換えてみましたが、それでも中止setValue:forKey:され、呼び出されていないと報告されます。

ここで何が欠けていますか？

ファイルのアップロードおよびダウンロード操作を処理する小さなライブラリを構築しており、一連のテストをそれに統合しようとしています。デリゲート コールバック メソッドを使用するのではなく、次のように完了ハンドラー ブロックで非同期応答を処理しています。

基になるuploadFileWithFilename...メソッドは次のようになります。

男がプリプロセッサの定義を使用し、OCMock を実際のコードベースに挿入している例を 1 つ見ました。それは私には間違っているようです。

このようなコードをテストするための最良の戦略は何でしょうか?

私は OCUnit を使用しています。次のメソッドで、WebService オブジェクト、またはメソッド「startSynchronous」の結果をモックして、独立した単体テストを作成するにはどうすればよいですか?

そこにコードを挿入して、モック Web サービスを作成するか、startSynchronous 呼び出しでモック データを返すことはできますか?

iOS プロジェクトで単体テストに BDD アプローチを採用したいのですが、さまざまなテスト スパイのテスト ダブルを提供する既存のライブラリがない可能性があることに気付きました。理想的には、 Mockito、Jasmine、またはRRに似たものを探しています。

テスト スパイ ライブラリの作成に 1 週​​間自由時間を費やす前に、ここでまず SO に関する質問を投げかけようと思いました。

これまでOCMockとKiwiを見てきましたが、どちらもact フェーズの前に、arrange フェーズで期待値アサーションを設定する必要がある、従来の高仕様のデフォルトのモッキング フレームワークのようです。明らかに、これは美しいDRYのネストされたスペック ( KiwiまたはCedarで作成する予定) の私のビジョンを妨げています。