回答。

問題の歴史:

スモークテスト（smoke tests、"煙"によるチェック）は、システムの基本的な機能がデプロイ後またはコード変更後に動作することを確認するための迅速な方法として最初に生まれました。そのイデオロギーは、「クリティカルな部分が壊れている場合は、詳細なチェックを実行する意味がない」というものです。自動化の初期のスモークテストは、アプリケーションの起動、ログイン画面へのアクセス、および基本的な操作の確認のための小さな手動スクリプトとして実装されていました。

問題:

スモークテストの自動化における主な課題は、最小限のシナリオの正しい分離、高速実行、安定性の低いコンポーネント（例えば、サードパーティサービス）への依存の最小化、およびそれらの「軽さと透明性」を視覚的および技術的にサポートすることです。これが達成されなければ、スモーク自動化は非常に重くなりすぎるか、頻繁に誤警報を出し、大規模なメンテナンスを必要とします。

解決策:

スモークテストの数を最小限に抑える：それには最もクリティカルな「エントリーポイント」（例：認証、メインモジュールの起動、データベースの可用性）のみが含まれるべきです。
不安定なステップや外部依存関係をスモークシナリオの外に持ち出すか、"スタブ"を使用して環境を安定させます。
タグ付け（@smoke、Suite('smoke') など）とCI/CDパイプライン内の別々のセクションを使用して、スモークテストを常に最初に実行します。

主要な特徴:

スモークシナリオは迅速に実行され、最も安定したインフラストラクチャの部分のみを使用する必要があります。
スモーククラスの自動テストは、UXの詳細や複雑なワークフローをカバーするべきではありません。
スモーク自動化は依存関係の厳格な管理と最小限のサポートコードを必要とします。

誤解を招く質問。

スモークセットにエッジケースロジックのチェックシナリオを追加してもよいですか？

いいえ、スモークセットはシステムの実行可能性と可用性の確認のみを目的としているため、エッジケースは不要で、実行を遅くしてメンテナンスを複雑にします。

スモークテストで多層エラーハンドリングとリカバリーを実装する必要がありますか？

しばしば誤って、スモークには複雑なリカバリーメカニズムが必要と考えられます。実際には、スモークテストが失敗する場合、それは修正すべき重大な問題を示す信号であり、自動テストで「回避」すべきではありません。

スモークテストは、他のテストによって残されたデータに依存するべきですか？

いいえ、スモークは外部のテストデータや他のテストの成果物に依存するべきではありません。これは、信頼性の重要な原則の1つです。

一般的な誤りとアンチパターン

スモークテストの過負荷：シナリオが多すぎて、回帰チェックに変わること。
スモークテストと通常の自動テスト間のコードの重複。
暗黙の依存関係：テストが他のシナリオからの「汚れた」データやアーティファクトを使用すること。

実生活の例

ネガティブケース

スモークシナリオセットに30の異なるチェックを追加し、その一部はシステム起動だけでなく複雑なアルゴリズムやエッジケースの条件もテストしています。スモークの実行が30分かかり、時折不安定なバックエンドのためにいくつかのチェックが失敗しました。

利点:

システムのボトルネックを簡単に見つけることができる。
デプロイ直後にテストの高いカバレッジ。

欠点:

スモークの本質が失われた："緑"ビルドは、重要でない問題を解決するための長い待機の後しか得られない。
テストのメンテナンスが困難で、実際のクリティカルな障害を特定するのが難しい。

ポジティブケース

スモークグループには厳密な最小限を持ち込みました：ログイン、メインページのオープン、データベースへのクエリ、基本的なAPIハンドシェイク。スモークフレームワークは、主要なテストマトリクスから独立して動作し、常にCI/CDパイプラインの最初に実行されます。結果は別のチャットで、迅速な診断のために常にアクセス可能です。