答え。

歴史的に、自動テストの数が増えるにつれて、テストが混乱し、実行時間の制限を超え、何が何に責任を持っているのか理解するのが難しかったという問題が現れた。さらに、テストシステムの異なる部分間の依存関係のリスクが増加し、全体のパイプラインの動作が遅くなる可能性もあった。

テストの数が、テストインフラストラクチャのアーキテクチャ的なサポートが確保されるよりも早く増加すると問題が発生する。スケーラブルなソリューションがない場合、テストは遅くなり、メンテナンスが難しくなり、欠陥の検索と特定が困難になり、技術的負債が急速に増大する。

解決策は、特別な戦略を導入することです：

• モジュールおよびレベル（ユニット、統合、E2E）に従ってテストをクラスタ化し、対応するタグやフィルターを使用する。
• テストを並列に実行（シャーディング、分散テストスイート）して、実行を加速する。
• テストのインフラストラクチャにマイクロサービスアプローチを使用する：標準的なDSL抽象化、テストインフラストラクチャ管理のための個別サービス。
• 繰り返しおよび古くなったテストの検出を自動化し、定期的なリファクタリングとカバレッジの監査を行う。

主な特徴：

• テストおよびテストライブラリのモジュール性と再利用性。
• CI/CD統合の完全自動化とリソースの自動スケーリングの可能性。
• 自動テストの品質とコードカバレッジを監視するツールの導入。

ひねりのある質問。

すべてのテストを統合テストにすることで、同時により多くのコードをカバーできますか？

いいえ、そのようなアプローチは欠陥の特定を困難にし、サポートコストが高くなり、回帰テストの実行が遅くなる可能性があります。

自動テストのスケーラビリティは、それらの加速だけを意味しますか？

スケーラビリティは、アーキテクチャ、メンテナンス性、加速、柔軟なインフラストラクチャに関するものです。加速は、よく設計された大規模なシステムの結果に過ぎません。

異なるタイムゾーンで作業するチームのためにテストを適切にスケールさせるにはどうすればよいですか？

ローカル実行の可能性とテスト環境の独立性を考慮することが重要です。そうしないと、チーム間で「競合」が発生します。

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

• すべてのテストが分野ごとに構造化されずに1つのディレクトリに書かれる。
• テストデータが直接再利用される（ライブラリ/フィクスチャの代わりに「コピーペースト」）。
• テストの実行時間と安定性に関する監視/メトリックがない。

生活の例

ネガティブケース

会社には、同じフォルダーに新しい自動テストを追加する複数のチームがすぐに登場しましたが、それぞれが自分の変更を調整していませんでした。数週間後、自動テストはデータと依存関係の不一致のために失敗し、実行時間は2時間を超えました。

プラス：

• 初心者にとっての低い参入障壁。
• 自動化の迅速なスタート。

マイナス：

• スケーラビリティの欠如。
• エラーの検索と分析の複雑さ。
• 製品のリリースの遅延。

ポジティブケース

1つのチームでは、モジュール構造を作成し、コードの分野ごとに独立したCIを導入し、安定性を向上させ、自動テストの非効率に関するアラートを導入しました。

プラス：

• サポートの簡素さ。
• 迅速なフィードバック。すべての欠陥が迅速に特定されます。
• テストの品質の劣化なしに負荷をスケールする可能性。

マイナス：

• 事前のアーキテクチャ分析とチーム間の合意が必要です。