現在のプロジェクトでは、受け入れテストに Specflow と WatIn を利用しています。顧客は、代わりに Microsoft coded-ui を使用することを望んでいます。コード化された UI をテストしたことはありませんが、これまで見てきたことからすると、面倒に見えます。いくつかの記録/再生の結果としてではなく、UI を作成する前に、受け入れテストを前もって指定したいと考えています。とにかく、Specflow/watin コンボを捨ててコード化された UI に置き換える理由を教えてください。
また、specflow をコード化された ui と組み合わせることができることも読みましたが、specflow で既に問題なく実行しているものに対して、多くのオーバーヘッドが発生しているように見えます。
これを行う方法についてのブログ投稿を書きました。
http://rburnham.wordpress.com/2011/03/15/bdd-ui-automation-with-specflow-and-coded-ui-tests/
私が考えることができるコード化された UI テストの長所と短所は、ユーザーがアプリケーションをどのように使用するかを正確にテストすることです。これは受け入れテストには適していますが、制限もあります。また、エンドツーエンドのテストにも非常に適しています。これまで、UI テストは脆弱であることが知られていました。たとえば、MS が VS2010 UI を作成したとき、ほとんどすべての UI テストが失敗しました。主な理由はテクノロジーの変化です。コード化された UI テストは、コントロールと一致する方法によってこれが発生するのを制限するのに役立ちます。確率ベースの一致をより多く使用します。これは、コントロール名などの情報に基づいて最適な一致を見つけようとすることを意味します。私たちにとっては、技術的な制限のため、コード化された UI テストが選択されました。私たちのレガシー アプリは VB です。CUIT はうまく機能しませんが、より良い制御情報を取得するための拡張機能を作成中ですが、それが唯一の選択肢でした。また、CUIT は新しく、独自の制限があることに注意してください。VS2010 の現在のエンド ツー エンドの動作により、UIMaps の維持は少し手作業になる可能性があるため、プロジェクトをレイアウトする方法で非常に構造化されるように準備する必要があります。たとえば、既存のアクション記録から CUIT を作成すると常にUIMap.uitest と呼ばれる UIMap のテストであり、それを変更したり、別の UIMap に転送したりする方法はありません。複数の ui マップを使用する場合、最初に手順を記録してからテストで使用する必要があります。ただし、.net であるため、依然として非常に柔軟です。VS2010 の現在のエンド ツー エンドの動作により、UIMaps の維持は少し手作業になる可能性があるため、プロジェクトをレイアウトする方法で非常に構造化されるように準備する必要があります。たとえば、既存のアクション記録から CUIT を作成すると常にUIMap.uitest と呼ばれる UIMap のテストであり、それを変更したり、別の UIMap に転送したりする方法はありません。複数の ui マップを使用する場合、最初に手順を記録してからテストで使用する必要があります。ただし、.net であるため、依然として非常に柔軟です。VS2010 の現在のエンド ツー エンドの動作により、UIMaps の維持は少し手作業になる可能性があるため、プロジェクトをレイアウトする方法で非常に構造化されるように準備する必要があります。たとえば、既存のアクション記録から CUIT を作成すると常にUIMap.uitest と呼ばれる UIMap のテストであり、それを変更したり、別の UIMap に転送したりする方法はありません。複数の ui マップを使用する場合、最初に手順を記録してからテストで使用する必要があります。ただし、.net であるため、依然として非常に柔軟です。複数の ui マップを使用する場合、最初に手順を記録してからテストで使用する必要があります。ただし、.net であるため、依然として非常に柔軟です。複数の ui マップを使用する場合、最初に手順を記録してからテストで使用する必要があります。ただし、.net であるため、依然として非常に柔軟です。
specflow の最も優れた点は、読みやすさと生きたドキュメントのための gerkin 構文です。通常、アプリのテスト機能または動作は、値がどこから来るかです。通常、UI のすぐ下のテストを目的としています。UI があちこちで変更されると、テストが中断される可能性が少し低くなります。私にとって Specflow は、アプリケーションが常に変化していて、既存の機能が引き続き機能することを確認したい場合に最適です。スクラム環境にもよく適合し、シナリオがどのように機能するかについての説明として記述できます。私が見ることができるspecflowへの1つの制限は、解釈のために開かれていることです。このため、再利用性が低く、保守が難しいテストを簡単に作成できます。「ユーザー 1 としてログイン」のように、より一般的な用語を使用して手順を説明するのが好きです。
ただし、この 2 つを組み合わせると、コード化された UI テストを使用するよりも有益に思えます。UI を完全に変更することを決定した場合、少なくとも期待される動作を、誰もが理解できる方法で specflow 機能に格納する必要があります。最後に、アプリケーションがどのように進化するか、およびアプリケーションのタイプを検討する必要があります。