LocomotiveJS を使用して MVC アプリケーションを構築しています。私は書くべきテストの種類について考えていて、混乱しています。
アプリケーションのさまざまなコンポーネント (モデル、ビュー、コントローラー、ルーター、ORM) は次のとおりです。
すべてのコンポーネントを単体テストする必要がある場合は、次のようにアプローチする必要があります。
- ORM が提供する API が期待どおりに動作することを確認するためのテストを作成します。
- ORM をスタブ化してモデルの単体テストを行います。単体テストで実際のデータベース操作に依存する必要がないように、スタブを提供します。
- コントローラーはビューとモデルにアクセスします。コントローラーの仕事は、モデルを取得/変更し、クライアントに応答 (レンダリング/リダイレクト) することです。
- コントローラーの応答は、テスト入力を提供し、正しい応答が生成されるかどうかを確認することでテストできます (スタブアウトし
renderてredirect、正しい呼び出しが行われることを確認します)。 - コントローラーによるモデル操作は、モデルをスタブ化し、正しい呼び出しが行われることを確認することでテストできます。私は実装をテストしているので、これは間違っていると感じています...
- コントローラーの応答は、テスト入力を提供し、正しい応答が生成されるかどうかを確認することでテストできます (スタブアウトし
- ビューは単なるテンプレートです。コントローラーはテンプレートを値にバインドします。偽のビュー モデルを作成してビューにバインドし、正しい出力が生成されるかどうかを確認できます。
- ルートはリクエストを受け取り、それを適切なコントローラーとアクションにマップするだけです。ルーターの一部をスタブアウトし、ルーターへのリクエストが予想されるコントローラー/アクションにマップされていることを確認することで、アプリが適切なルートをサポートしていることを確認できます。
今、モデル API を変更するとします。モデル テストを変更する必要があり、コントローラー テストで使用されるモデル スタブを変更する必要があり、コントローラー テストでアサーションを更新する必要があります。
これはやり過ぎのようです。
これはむしろ理にかなっていますか？
上記の 1 と 2 を実行します。
3.残りの統合テスト（コントローラー/ビュー/ルーター）。testここでは、環境でアプリを起動しsupertest、リクエストが適切な応答を生成するようにするために使用する必要があると思います-URLにアクセスすると、適切なコンテンツが取得され、適切なリダイレクトなどが行われます.
モデルは別のシステムとの相互作用 (データの永続性) を表しているため、モデルを単体テストするのは理にかなっていると思います。ブリッジが適切に機能することを確認したいと考えています。ルーター/コントローラー/ビューは、独自のシステム内で非常に具体的な方法で対話します。したがって、それを統合テストしても問題ないようです。あなたの考えは何ですか？