そのため、この時点で、現在のプロジェクトでデイリービルドを何ヶ月も実行しています。ただし、デイリービルドに伴うスモークテストはそれほど複雑ではありません。メインクラスライブラリでいくつかのnUnitテストを実行し（確かに、優れたコードカバレッジは提供されません）、コンパイルが確実に行われるようにします。ビルドします。問題のアプリケーションは、いくつかのビジネスオブジェクト（LINQ-to-SQLを含む）を使用するASP.NETサイトです。
特にASP.NETサイトで実行する必要がある、より複雑なスモークテストはありますか？さらに言えば、ASP.NETサイトのスモークテストをどのように開発しますか？
単体テストだけでなく、いくつかのサンプル データを使用してステージング サーバーにサイトを立ち上げるとよいでしょう。限りなくライブに近い。次に、HTTP トラフィック生成スクリプトを使用して、ユーザー トラフィックとセッションをシミュレートします。バックエンドでデバッグ ロギング、例外、その他のテスト コードを監視できます。ここでパフォーマンス測定を行うこともできます。
ブラウザで自分で遊んでいる、より強烈で反復的なバージョンによく似ています。
これを行うには、パブリック リソースとその入力を定義する (または調査する) ことによって行います。スクリプトは、検証の問題、サイト フローの奇妙な順列、およびライブ設定でサイトのコンテキスト全体をテストするその他のことを試みて引き起こす可能性があります。
テストが完了していない場合...単体テストから「実際のデータとトラフィックでうまく機能するか」まで、最終的には頭のない鶏のように後でバグを修正することになります。
スモーク テストは本来、表面的なものである必要があります。つまり、コンパイルできますか? 配備？ウェルカム ページはロードされますか? データベースに対してクエリを実行するテスト ページをロードして、この接続も機能することを確認してください。それでおしまい。
スモークテストを行うべきではありません。その言葉の語源を知っていますか？電子機器の「煙テスト」は、電源を入れて煙が出るかどうかを確認することです。
より包括的な単体テストを行う必要があります。適切なコード カバレッジを提供するには十分です。これは、すべてのビルドで行うべきことです。また、展開を試みて、いくつかの「インストール検証テスト」を実行する必要があります。