なぜコードをコピーする必要があるのですか? Cassini はやめて、Visual Studio に仮想ディレクトリを作成してもらいましょう。Web アプリが変更された場合、開発者は Web テストを実行する前にビルドすることを忘れないでください。特に CI で Web テストを実行する場合、これは大した問題ではないことがわかりました。
データは大きな課題です。私の知る限り、不完全な選択肢の中から選択する必要があります。対処方法は次のとおりです。まず、大規模で複雑な従来の WebForms アプリを使用していることを説明する必要があります。また、ドメイン コードは、テスト プロジェクト内からテスト データを作成するのには適していません。
これにより、いくつかの選択肢が残りました。(a) ビルドの下でデータ セットアップ スクリプトを実行するか、(b) 実際の Web サイトを使用して Web テストを介してすべてのデータを作成します。オプション (a) の問題は、テストが細かいレベルでスクリプトと結合されることです。Web テスト コードを T-SQL と同期させることについて考えると頭がドキドキします。そこで、(b) を採用しました。
(b) の利点の 1 つは、セットアップでアプリケーションの動作も検証されることです。問題は...時間です。
理想的には、テストは独立していて、一時的な結合がなく (任意の順序で実行できます)、コンテキストを共有していません (共通のテスト データなど)。これを処理する一般的な方法は、すべてのテストでデータを設定および破棄することです。慎重に検討した結果、このルールを破ることにしました。
私たちは、私たちの戦略をサポートする優れた機能を提供する Gallio (MbUnit 3) を使用しています。まず、フィクスチャおよびテスト レベルで実行順序を指定できます。-4、-3、-2、-1 の 4 つの「セットアップ」フィクスチャがあります。これらは、指定された順序で実行され、デフォルトでは順序が 0 のすべての「セットアップされていない」フィクスチャの前に実行されます。
私たちの Web テスト プロジェクトは、単一の既知のユーザー名/パスワードという 1 つのことだけをビルド スクリプトに依存しています。これは私が一緒に暮らすことができるカップリングです。セットアップ テストが実行されると、データの識別子 (会社、ユーザー、ベンダー、クライアントなど) を保持する「データ コンテキスト」オブジェクトが作成されます。このオブジェクトは、後で他のすべてのフィクスチャで使用されます (変更されることはありません)。(識別子とは、必ずしもキーを意味するわけではありません。ほとんどの場合、Web UI は一意のキーを公開しません。真の識別子の名前または他のプロキシを使用してアプリをナビゲートする必要があります。これについては以下で詳しく説明します。)
Gallio では、テストまたはフィクスチャが別のテストまたはフィクスチャに依存するように指定することもできます。前例が失敗すると、従属はスキップされます。これにより、多くの混乱を招く可能性のある「カスケード障害」が防止され、一時的な結合の弊害が軽減されます。
各テストの前ではなく、ベースライン テスト データを 1 回作成すると、作業が大幅に高速化されます。ただし、セットアップ テストの実行にはまだ 10 分かかる場合があります。新しいテストに取り組んでいるときは、頻繁に実行して再実行したいと考えています。もう 1 つの優れた Gallio 機能であるアンビエンスを入力してください。アンビエンスは、オブジェクトを永続化するための非常に簡単な方法を提供する DB4 のラッパーです。これを使用して、データ コンテキストを自動的に永続化します。したがって、セットアップ テストは、データベースの再構築の間に 1 回だけ実行する必要があります。その後、他のフィクスチャの一部またはすべてを繰り返し実行できます。
では、テスト データのクリーンアップについてはどうでしょうか。既知の状態から開始する必要はありませんか? これは、破る方がよいと判断したルールです。私たちにとってうまくいっている戦略は、会社名、ユーザー名などに長いランダム値を使用することです。衝突しないように、論理的な「データ空間」内でテストを実行し続けることはそれほど難しくないことがわかりました。他のデータに。確かに、テストに失敗したファントムを何時間もかけて追跡し、それがデータの衝突であることが判明する日を恐れています。これは、現在私たちのために働いているトレードオフです。
私たちはWatinを使用しています。めっちゃ好きだよ。成功へのもう 1 つの鍵は、Scott Bellware がほのめかしたものです。テストを作成すると、UI の抽象モデルが構築されます。したがって、これの代わりに：
browser.TextField("ctl0_tab2_newNote").TypeText("foo");
これは、テストで確認できます。
User.NotesTab.NewNote.TypeText("foo");
このアプローチには 3 つの利点があります。まず、魔法の文字列を繰り返すことはありません。これにより、もろさが大幅に軽減されます。第二に、テストは非常に読みやすく理解しやすいものです。最後に、Watin フレームワークのほとんどを独自の抽象化の背後に隠します。2 番目の例では、TypeText だけが Watin メソッドです。これにより、フレームワークの変更に合わせて変更しやすくなります。
お役に立てれば。