問題タブ [mockery]

Posts クラスと Blog クラスがあります。

以下からわかるように、Posts クラスは Blog クラスに依存しています。

このアクションの URL は次のとおりです。

これをテストしようとしていますが、問題が発生しています。

これが私のテスト クラス PostTestController です。

問題はこれです... get 自体にデータに基づく変数出力が含まれている場合、get 呼び出しをテストするにはどうすればよいですか? これを正しくテストするにはどうすればよいですか?

適切なテストが行​​われるように、既存の Laravel 4 アプリケーションを書き直しています。AccountController簡単に言うと、 TDD メソッドを使用してクラスを書き直しましたが、少し頭が痛くなりました。

ユーザーのリストを含むページをレンダリングする次のメソッドを検討してください。

Smarty を使用してビューをレンダリングし、認証のために Sentry を使用しています。

ここで、次のようなテストをいくつか書きたいと思います。

私は Jeffrey Way の著書Laravel Testing Decodedに従い、上記のようなテストを書きましたが、問題なく動作します。

頭痛の種は、「ここにいくつかのモックを設定してください...」セクションで発生します。特に、設定する必要があるモックの数はばかげています。これは、より大きな Web アプリケーションの一部として、現在のユーザー モデル、メニュー構造、アラート メッセージ、ニュース メッセージ、アプリケーションのバージョン番号などのデータを View モデルに追加する View コンポーザを使用しているためです。テスト用に「必要最小限の」テンプレートを使用して、これらの多くを切り取りましたが、まだ多くのものがあります。この単純な 1 行のメソッドをテストするために、何百行ものコードを記述しているほどです。

これを行うより良い方法はありますか？

私の見方では、これを行うには2つの方法があります。

A. 私がやってきた方法

B.\View::makeすべてのテンプレート レンダリングがバイパスされるように呼び出しをモックする - このようなもの

このアプローチを採用すると、テストははるかに簡単になり、コントローラー メソッドに実際にあるコードのみをテストしますが、そのルートの呼び出しに関連するすべてを実際にテストするわけではありません (これは良いことかもしれませんし、そうでないかもしれません)。 -よくわかりません)そして、十分な補償を受けられないのではないかと心配しています.

では、これを行う最善の方法は何ですか: (A)、(B)、または他の何か?

編集

私のコントローラーメソッドのテストに関して、私の側にはかなりの混乱があります。これは、@TheShiftExchangeの回答と以下のコメントによって明確になりました。編集として、ここで問題に対処しようとします。これにより、質問について話し合う余地が少し増えるからです。

以下の回答にある 2 番目の例を考えてみましょう。

このテストを実行すると機能しますが、データベースにアクセスします。これは、いくつかのものをモックして回避しようとしていました。

したがって、このテストを少し拡張できます。

コントローラー メソッドに必要なモックに加えて、ビュー コンポーザーのコードにもモックが必要になるため、このテストは機能しません。このコードには、とりわけ次のものが含まれます$currentUser = \Sentry::getUser()(ユーザーの名前は、アプリケーションのページの右上隅に表示されます)。

したがって、コードは実際には次のようになります。

そして、それはすぐに手に負えなくなります。

これは、私が何か間違ったことをしていることを示唆していますが、何が間違っているのかわかりません。この問題は、ここで何をテストしているのか正確にわからないことが原因であると思われます。

それで、結局のところ、質問は次のようになります。

コントローラーのメソッドをテストしているときに、実際にテストしようとしているのは何ですか?

1. コントローラのメソッドのコード? または、

2. リクエストからレスポンスまでの全プロセス？

テストしたいのは最初の項目です。コントローラー メソッドのコードだけです。私の質問の例は非常に単純ですが、ユーザー入力に基づいてフォームの検証やリダイレクトなどを行うコントローラーメソッドがいくつかあります。そのコードをテストしたいと思います。

を介してコードをテストするのではなく、$this->call()単にコントローラ メソッドを直接呼び出す必要があるのでしょうか。

単体テスト中にLaravelでいくつかのファサードをモックしようとしていますが、テストは常に成功しているようです。

たとえば、次の例は Laravel のドキュメントから抜粋したものです。

Eventそれを任意のテストメソッドに入れることができるようで、ファサードで何も行われていない場合でも、常に合格します。

テストクラスは次のとおりです。

Facades をテストするために不足しているものは何ですか? shouldReceive()セットアップなしで Laravel Facadeを呼び出すことができるはずだと考えているのは正しいですか?

Str::random()テストしたいクラスがあります。

しかしStr::shouldReceive('random')、テストで使用すると、メソッド shouldReceive が存在しないという BadMethodCallException が発生します。

また、クラスを直接モックして IOC にバインドしようとしましたが、元のクラスを実行し続け、モックに設定した戻り値ではなく、ランダムな文字列を生成します。

Laravel 4 と Mockery を使用して、コントローラーの単体テストをいくつか作成しています。

コントローラーメソッドを直接呼び出す (メソッドを分離して単体テストするため) と、ルートを介してメソッドを呼び出す (応答に焦点を当てるため) の両方でテストしてきましたが、コントローラーを呼び出すかどうかに基づいて異なる答えを得ています。ルートを経由します。

これが私の機知に富んだコントローラーです：

これが私のルートです：

そして、ここに私のテストがあります：

でコントローラーへの直接アクセスをテストしていることがわかりtestDestroyOk()ますtestDestroyOkRoute()。prepDestroyOk()両方のテスト ケースは、一貫性を確保するために共通の方法を使用してセットアップされます。

それでも、コントローラーのメソッドから ResourceNotFoundException をスローするため、成功して失敗しますtestDestroyOk()。testDestroyOkRoute()getUser()

コントローラーへのアクセスが機能するのに、ルートを経由するのがどういうわけか異なる方法で処理される理由はありますか?