0

私は最初のコントローラーテストを書いています。内部的には、コントローラーはデータベースへの接続を試みるファイルを呼び出す (または拡張する) 必要があります。ただし、実際にデータベースに接続する必要はありません。これは、現在テストしているものとまったく同じではないためです (...または、そうすべきでしょうか?)。とにかく、データベースへの呼び出しをモック/スタブするにはどうすればよいですか (正しい用語が何であるかはわかりません)。または、少なくとも通話を傍受して、すべての通話がどこで発生しているかを知るにはどうすればよいですか?

4

1 に答える 1

1

一般的な回答: はい、ここでは「嘲笑」が適切な用語です。既知の入力を受け取り、既知の出力を生成する「偽の」オブジェクトを作成したいと考えています。

まず第一に、私は Zend Framework コントローラーをテストした経験がありません。SO の質問から判断すると、かなり複雑なようです。したがって、いくつかのサンプルコードがないと、実際に機能する/機能する例を作成できません。

ただし、実際にデータベースに接続する必要はありません。これは、現在テストしているものとまったく同じではないためです (...または、そうすべきでしょうか?)。

まず、実際にデータベースに接続するかどうかはわかりません。「純粋な」形式の単体テストでは、偽のデータベース (メモリ内の sqlite) に対して作業するように指示されますが、現在、クエリが実際の db インスタンスに対して機能することを確認したいので、データベース アクセス オブジェクトを実際の db で再度テストします。それは私を次のポイントに導きます。

コントローラーはデータベースと通信するべきではありません。データベースと直接通信する (すべて/多くの) モデルでさえ、多くの人が適切な MVC と見なすものではありませんが、コントローラーに SQL を配置することは、php 4 日前にアプリケーション ロジックの PHP コードに html を配置することと同等です。

非常に一般的な答えとして:

$objectToMockOutInQuestion を取得するコードを見てください。コンストラクターパラメーターのメソッドから取得した場合は、それを渡すことができます。コードがコンテナーからプルする場合は、事前にそのコンテナーに入れることができるかどうかを確認してください。それが単純な古いnew演算子である場合は、コードを変更することをお勧めします。

テキストだけでもお役に立てば幸いです

于 2011-08-25T07:40:54.300 に答える