PV0連日すみません。昨日の件は解決できましたありがとうございました次にactionsheetに追加する部分が通るか確認するテストコードを書いていたのですが、また、エラーが。verify];}こういったエラーが。ググってみたところいっぱい出てきたのですが、大体ここに書いてあるhttp://stackoverflow.com/questions/18932544/nsinvalidargumentexception-reason-sheet-can-not-be-presented-because-the-vi2つとも試したのですが、結果は同じでした。(0)エラーから見るにshowEraseSheetで落ちているような気がしますのでその辺りがどう動くのか見てみるといいかもしれません。mockelaserもshowEraseSheetも名前しか出てこないので何とも言えないです。スタックトレースは出てないんでしょうか。更新順-1根本的なレベルから間違っているので、「ユニットテスト」「テストケース」「JUnit」などを一から勉強しなおしてください。そもそも今回のテスト対象は何なのでしょう?テストケースの中にアサーションが一つもないのはありえません。ユニットテストは、MVCのうち主にModelをテストするものです。ViewやControllerのようなユーザーインターフェースはほとんどテストできません。通常ViewControllerに書いてるコードを、TestCaseに書き写してもテストになりません。22:04Mockオブジェクトの話は関係ありません。ユニットテストそのものの話です。12:19アサーションがないというのは何をもっていっているのでしょう?調べましたか?ocmockはverifyを呼び出すとあらかじめexpectで設定した期待と異なる動作をした場合に自動的にテストを失敗にしてくれる機能があります。12:45verifyは自動的にテストを失敗にするのではなく、例外を発生させるのです。13:02例外が起こることを期待するならそうでしょう。これは例外のテストではありません。13:24XCTAssertNoThrow()を使って「ここでは例外が発生しない」と書いてください。13:36普段Assert文以外は全部そうされているんですか?XCTAssertNoThrowで囲むと余計な失敗情報(「ここでは~」のことじゃないですよ)が増えますし、フォーラムやstackoverflowその他でそのようにテストしている人を見かけたことがないので、私はチュートリアルなどで見かける形で扱っていこうと思います。14:32ocmock作者のiPhoneのサンプルでもSTAssertNoThrowは使っていませんので、XCTAssertNoThrowなどを使うよう推奨すべきというのは作者に提案されるとよろしいかと思います。ここで議論するようなことでもないでしょう。3点について続けて回答させていただきますが、私はサンプルやチュートリアルに従う形をとります。これ以上は議論を広げるつもりもありませんので回答は結構です。ocmock作者の使用例含めネットで見た限りverifyをそのまま呼び出せばよいように見受けられました。それでもテストフレームワーク標準のアサーションを使うべきと主張されておられるので、ではどこまでをアサーションで対処すべきと考えておられるのかがわかりませんでした。14:12(例えばniceでないmockの未定義メソッドが呼び出されると例外です。14:12一切起きてほしくないのでAssert文以外すべて例外を補足すべきなのか、それ以外なのか。前述の通り回答は結構です。verifyをそのままの場合の失敗メッセージと、XCTAssertNoThrowなどで囲んだ場合の失敗メッセージを単純に比較した場合、XCTAssertNoThrowのメッセージが先頭に数行付け足されるような恰好になります。14:13実際に見たいのはverify(またはほかの例外)のメッセージなので、verifyをそのまま呼び出せば良いと思っている私にとっては先頭に余計な情報が追加されるように感じたという意味です。私の回答の前のコードへの指摘かと思います(stripeさんの2つ目の指摘「expectしたメソッドは~」はちょうど自分のコメント書いていて見落としていました。stubの代わりにexpectを使ったつもりはありません。expectで指定したものはテスト対象です。単純にコードのミスです。14:14長文・連投失礼いたしました。私の回答の前のコードへの指摘かと思います」>違います。verifyを書いたのかということです。stubを使っていればverifyは書かないのだから、例外について議論になることもなかったはずです。verifyを使った理由は、メソッドが呼ばれたことを(または呼ばれなかったことを)明示的に確認するためじゃないんですか?テストケースにおいて、結果を確認するためにAssertを書いて表明するのは基本中の基本です。逆に確認するつもりがないものについてAssertを書く必要はありません。verify])と書き、特に確認するつもりがないならstubを使えばいいのです。17:02あなたが見たサンプルは「あくまでもocmockのサンプルコード」だったんじゃないんですか?そもそもXCTAssertNoThrow()で例外を補足しなかったら、後続のAssertが処理されなくなるじゃないですか。17:19-1すいません、stripさんの指摘の通りコードが間違ってました。ActionSheetを作成していたためです。最初showEraseSheetがただのメソッドだとおもっていたんですが、途中でIBActionだと気付いて意図せずオーバーロードになってしまっていました(ただの言い訳です)。showEraseSheetのAction時には設定する必要はありませんでした。ここを修正するとテストはパスします。さんのコードでもaActionSheetがメソッド呼び出しによって変更されていないか確認してみてください。setupの待ち時間の長さに挫折しそうになりましたが試しにやってみました。説明がなかった部分は想像で書いています。最初コードが間違っていたため再現したように見えましたが、修正によりテストは通過するようになりました。Applicationにボタンを置き、以下のようなコードで発生します。以下は不要になりました。showInViewのみになりました。verify];}で、これを書く前に試しで書いてみたコードだとうまくいきました。上記コードに以下の様に追記します。verify];}参考までにどうぞ。13:46修正後のコードがうまく行っているように見えるのは、ocmockの機能を使って本来発生するはずのエラーを消し込んでいるからだと思います。14:22本来発生するはずのエラーを消し込んでいるとは具体的にどこのことでしょう。ちなみに普通に起動してiOSシミュレータで起動実行できます(質問者の形式のコードもシミュレータでは動作します。テストランナーからだとエラーですが)。showInView:vc.view];のことです。mockACのshowInView:が呼ばれることをテストできますが、UIActionSheetのshowInView:が呼ばれる訳ではありません。14:51二つ目見落としてました、すいません。たしかにテストコードが間違っていました。14:59ウォッチこの質問への回答やコメントをメールでお知らせします。