最近、デスクトップ アプリケーションのユニット テストを C# で記述して実行する仕事を任されています。これまでは、主に自動化された機能/GUI テストを作成してきました。これらのテストは、クラッシュ、データ損失、ブルースクリーンなどを引き起こす可能性があるため、専用の QA マシンで実行されます。単体テストを実行するために同様の設定を行う必要がありますか? ローカル マシンで単体テストを実行することにリスクはありますか?
4 に答える
単体テストは、ローカル マシンとビルド サーバーで実行する必要があります。これらは、開発者へのフィードバックとして非常に貴重なリソースです。開発者は単体テストを作成する必要があります。チェックインする前に、単体テストを実行して、何も壊れていないことを確認する必要があります。次に、ビルド サーバーは単体テストを再度実行して、実際に壊れたものがないこと、および他のコードとの統合があればそれが成功したことを確認します。
単体テストが実行されたら、できればビルド サーバーで統合テストと自動化された UI テストを実行する必要があります。これらのプロセスが終了すると、既知の欠陥がないビルドが作成されます。少なくとも、テストでカバーされる欠陥はありません。言い換えれば、グリーン ビルドとは、ソフトウェアの統合がうまくいったことを意味し、開発者はチェックインを続けることができます。または、実際にソフトウェアをリリースする前に、ある時点で手動テストを開始できます。
十分な数のテストが自動化されると、ソフトウェア テストの涅槃が起こります。これにより、開発者とビジネスは、この一連の自動化されたテストの成功のみに基づいて製品を安全にリリースできると感じることができます。実際には、これほど完成度の高い製品はごくわずかで、ある程度の手動テストが必要です。
単体テストは、外部システムやインターフェースには触れません。したがって、ローカルで実行してもリスクはありません。
単体テストは、それ以上のセットアップなしですべてのマシンで実行できるように分離する必要があります。単体テストは、定義上、外部システム (データベース、ファイル システムなど) に触れることなく、非常に細かいレベルで機能単位のみをテストします。
単体テストは通常、開発中に開発者によって行われます。したがって、開発環境で実行してください。おそらくあなたのローカルマシンです。
ローカル マシンが開発マシンである場合、そのマシンは運用エンド ユーザー マシンではないため、リスクはないと思います。また、TFS ラボの管理を検討することもできます (Microsoft TFS を ALM / ソース管理システムとして使用している場合)。その場合、仮想または物理テスト環境を作成でき、アプリケーションはそれらの定義された環境で展開およびテストされます。
非 TFS シナリオ用の同様のテスト製品の名前が不明です。