単純なWebForms（asp.net）ベースのUIをテストし、MVPパターンに従って、UIをよりテストしやすくしようとしています。
バックエンドアルゴリズムのTDD方法論に従うと、DRY原則（Do n't Repeat Yourself）の精神で行われる単体テストのリファクタリングがいくつかあることがわかります。Rhino Mocksを使用してこれをUIに適用してインタラクションを検証しようとすると、ビューまたはモデルの期待値を設定するときに、コントローラーテストに多くの共通点が見られます。
私の質問は、もしあったとしても、通常、このリファクタリングをどこまで行うのかということです。他のTDDerがMVC/MVPベースのUIをどのようにテストしているかを知りたいです。
標準コードのようにテストをリファクタリングしません。共通の基本クラスやヘルパー メソッドなどにリファクタリングするにつれて、テストはより不明瞭になり始めます。テストはそれ自体で十分に明確である必要があります。
DRY はテスト対象ではありません。
とはいえ、一般的に行われている多くの配管作業があり、それらは抽象化する必要があります。
単体テストは、テストする必要がないように、純粋な関数型プログラムとして扱いたいと思います。テスト間で操作が十分に一般的である場合は、標準のコードベースで評価しますが、それでも、特にGUI駆動のBLの場合はテストが多い傾向があるため、リファクタリングテストは避けます。
私は機能テストにセレンを使用しており、コントローラーのテストにはJUnitを使用しています。
コントローラーが使用するサービスまたはリソースをモックアウトし、コントローラーがリダイレクト先のURIなどを確認するためにテストします。
この時点で実際にテストしていないのは、ビューだけです。しかし、私はそれを補うために機能テストを採用しました。
私は MVP を使用しており、テストでは、標準コードで行うリファクタリングのほとんどを適用しようとしています。さまざまなシナリオをテストするために必要なわずかなバリエーションのため、通常、テストではうまく機能しませんが、部分的に共通性がある可能性があり、可能な場合は統合します. これにより、後でプロジェクトが進化するにつれて、必要な変更が容易になります。標準コードと同様に、20 箇所ではなく 1 箇所を変更する方が簡単です。