Threat Stack がコンテナを使用してマイクロサービス テストを自動化する理由

マイクロサービスは、正しく設計されていても、テストが難しい場合があります。 しかし、システム アーキテクチャが進化し、絶えず変化するインフラストラクチャ内で数十または数百の接続されたサービスがソフトウェア プラットフォームを構成するようになると、自分とチームが担当する製品のテストは途方もなく複雑な作業になります。 これらの環境向けのテスト自動化を作成するのは難しいため、作成したテストから最大限の価値を引き出せるようにする必要があります。

Threat Stack では、グレー ボックス機能テストの一種であるシステム統合テストを作成し、コンテナー化されたテスト環境を実行するために Docker を選択しています。

他の種類のテストの何が問題なのでしょうか?

一部の組織では、依然として従来のテスト モデルに依存しており、ホワイト ボックス テストとブラック ボックス テストは十分な補完的なテスト戦略であると見なされています。 これらは依然としてソフトウェアの適格性を判断する上で重要な役割を果たしますが、自信を持ってソフトウェアをリリースするために必要なフィードバックを提供するにはもはや十分ではありません。

このような環境では、ブラック ボックスのユーザー受け入れテストは広範囲に及ぶため、それに依存すると、市場投入までの時間戦略に重大な影響を及ぼす可能性があります。

• テストの実行に割り当てられた時間内にテストするシナリオが多すぎるため、十分なカバレッジが提供されません。
• 実行時間は長く、アプリケーションの制御外の要因によりタイムアウトになることがよくあります。
• ビルド時ではなく、サービスがデプロイされた後に実行する必要があるため、フィードバックは製品開発からさらに分離されます。 テスト エンジニアリングを支配するシフト レフトの哲学では、このテストに依存すると組織の競争力が低下します。
• ブラックボックステストであるため、失敗の原因を特定するのは非常に困難な作業になる可能性があります。
• 開発者が簡単に記述したり保守したりすることはできません。

一方、ホワイト ボックス ユニット テストは焦点が狭すぎるため、ソフトウェア システムの機能性を評価するために誤って使用されることがよくあります。

• コンポーネントや他のサービスと対話するサービスの実際の動作は考慮されません。
• 維持するほど価値のない無意味なシナリオをテストできます。
• コードの小さな変更のために大量のテストコレクションを継続的に更新する必要がある開発者にとっては、面倒な作業になる可能性があります。
• テストエンジニアが簡単に記述したり保守したりすることはできません。

システム統合テストに重点を置く理由は何ですか?

Threat Stack のテスト エンジニアは、テスト範囲を最大化すると同時に、アプリケーションがさまざまな動作条件下で適切に動作することを保証するために必要な速度と特定性を提供する方法で、これらすべてのサービスをテストするために、システム統合テストにますます依存するようになっています。

統合テストは、外部コンポーネントとインターフェイスする際のテスト対象のソフトウェアまたはシステムの動作に重点を置いたグレー ボックス テストです。 例えば：

• データストア（PostgreSQL、Cassandra、ElasticSearch など）
• メッセージブローカー（例：Kafka）
• HTTP サーバー

つまり、対話して動作を検証できるソフトウェアです。 Threat Stack では、主に実際の状況を再現する機能テストを実行しますが、テスト対象の動作はコンテナ化された環境の境界で停止し、不要な外部とのやり取りを回避します。

また、これらのテストはマイクロサービスと密接に結合されているため、自動テストでテスト対象のサービスのコードを調べて統合し、実行するコード領域を一貫して特定できるという利点があります。 さらに、これらのテストはユーザー受け入れテストとして記述できるため、製品マネージャーや QA エンジニアなどの開発者以外のユーザーでもテスト対象の動作を簡単に理解できます。

言い換えると：

いくつかの条件が与えられた場合

サービスがこの入力を受け取ったとき（またはこの条件がサービスに影響するとき）

その後、サービスは期待どおりに動作し、期待どおりの副作用が発生します。

これらの機能テストは理解しやすく記述しやすいだけでなく、マイクロサービスのコードと密接に結合されているため、開発プロセス全体を通じて開発者が簡単に実行および更新したり、その後に専任のテスト エンジニアが簡単に実行および更新したりできます。

コンテナを使用する理由は何ですか?

コンテナは、テスト期間中に最小限のリソースでテスト環境をすばやく再現し、テストの実行が終了したら簡単にクリーンアップできるため、テスト システムに非常に役立ちます。 多くのブラック ボックス テスト自動化とは異なり、統合テストを実行するために高価な常時稼働のテスト環境は必要ありません。 テストを実行すると、マイクロサービスの動作をテスト環境で再現できます。 

運用中のマイクロサービスの環境を反映するコンテナ化された環境を定義すると、テスト フレームワークは、テスト対象のコンポーネントまたはマイクロサービスとインターフェイスする外部クライアントまたはモック サービスになります。 これにより、テスト コードがテストのすべての側面を駆動するようになり、テストのさらに多くの側面を制御できるようになります。

始める際には、 Docker はコンテナ化された環境を素早く立ち上げるのに適したプラットフォームです。 Docker Compose を使用すると、同じコードを使用して、ローカルまたは CI でテスト対象のアプリケーションのセクションを簡単に定義して実行できます。 組織が使用をサポートしている場合は、 Kubernetes 、 AWS EKS 、 AWS Fargateなどの他のコンテナ インフラストラクチャ ツールやサービスを使用してテスト環境をデプロイすることもできます。

結論

最終的に、他の種類の自動化ではなく統合テストにテスト作業を集中するという決定には、2 つの大きな利点があります。

• マイクロサービス テストは左にシフトされるため、デプロイメントの前に実行され、反復的な開発に対するフィードバックがより迅速に得られます。
• 実際のサービスとコンポーネントに対してテストを実行するため、テスト カバレッジのギャップは削減されますが、機能テストは引き続き実行されます。