私のプロジェクトでいくつかの単体テストを作成したいのですが (テストは初めてです)、オンラインのチュートリアルでは、最も単純なもののみをテストする例が示されているようです。
私がテストしたいのは、SurveyController で addAction に POST を送信した後、対応する行が調査と質問のテーブルに追加される場合です (1 対多)。
データベース関連のものをテストするためのベスト プラクティスは何ですか? テスト環境用に別個のデータベースを作成し、そこでテストを実行しますか? それが唯一の正しい選択肢ですか？
それはあなたの状況に依存します。
これについての私の見解は次のとおりです。
アイデアはテストすることですが、DRYでもあります（繰り返してはいけません）。コンポーネントが完全にテストされ、リリースの準備ができていることを確認するために、テストはすべてまたは可能な限り多くの異なるケースをカバーする必要があります。
Doctrine、Zend Framework、PhalconPHPなどのデータベースにアクセスするためにすでに開発されたフレームワークを使用している場合は、フレームワークがテストされており、実際のCRUD操作はテストされていないと見なすことができます。あなたはあなた自身のコードが何をするかに集中することができます。
それでもテストしたいと思う人もいるかもしれませんが、私の見解では、それはやり過ぎであり、リソースの浪費です。さらにテストを行いたい場合は、実際に特定のフレームワークのテストを独自のフレームワークに含めることができます:)
ただし、データベースレイヤークラスとそのアプリケーションとの相互作用を担当している場合は、テストが必須です。データベース操作が機能することを証明するために必要な場合、またはコードの一部を介して実行しない場合は、常に実行する必要はありませんが、実行する必要があります。
最後に、 Mark Bakerがコードで提案したようにモックテストを使用し、データベースが期待どおりに応答すると想定できます（すでにテストされているため）。次に、アプリケーションがさまざまな応答または結果にどのように反応するかを確認できます。
データベース操作をモックすると、テスト自体にデータベースの相互作用がないため、実際にテストの実行が速くなります（この戦略に伴う他の利点もあります）。これは、数千とは言わないまでも数百のテストと継続的インテグレーションを備えたプロジェクトで非常に便利になります。
HTH