テストポートフォリオがピラミッド型にするべきか、ハニカム型にするべきかについては議論があります。この議論に対する私の2番目に大きな問題は、ユニットテストと統合テストの違いを人々がどのように捉えているかが明確でないため、不透明になっているということです。

ブロードスタックテストとは、大規模アプリケーションのほとんどの部分を実行するテストです。これは、多くの場合、エンドツーエンドテストまたはフルスタックテストと呼ばれます。これは、システムの明確に定義された部分のみを実行するコンポーネントテストとは対照的です。

ビジネス向けテストとは、顧客、ユーザー、ビジネスアナリストなど、開発チームのプログラミング以外のメンバーとのコミュニケーションを支援することを目的としたテストです。自動化された場合、それらはシステムをドメイン指向の用語で記述し、システム自体のコンポーネントアーキテクチャを無視します。ビジネス向けテストは、多くの場合、受入基準として使用され、そのようなテストがパスすることを示すことで、システムが顧客が期待する機能を提供していることがわかります。

コンポーネントテストとは、テスト対象のソフトウェアの範囲をシステムの一部に限定するテストです。これは、システムをできるだけ多く実行することを目的としたブロードスタックテストとは対照的です。

テストダブルを使用する最も一般的なケースの1つは、外部サービスと通信する場合です。通常、このようなサービスは異なるチームによって保守されており、速度が遅く、信頼性の低いネットワークの影響を受ける可能性があり、それ自体が信頼性が低い可能性があります。そのため、テストダブルは便利です。独自のテストが遅く、信頼性が低くなるのを防ぎます。しかし、ダブルに対してテストを行うと、ダブルが実際に外部サービスの正確な表現であるかどうか、そして外部サービスがそのコントラクトを変更した場合に何が起こるかという疑問が常に生じます。

統合テストは、独立して開発されたソフトウェアのユニットが互いに接続されたときに正しく機能するかどうかを判断します。この用語は、ソフトウェア業界のあいまいな基準によってもあいまいになってきているため、私は自分の文章で使用することに慎重になっています。特に、多くの人は統合テストは必然的に範囲が広いと考えていますが、より狭い範囲でより効果的に実行できます。

ストーリーテストは、ユーザーストーリーの一部として提供されるソフトウェアを記述および検証するために使用されるビジネス向けテストです。ストーリーが詳細に説明されると、チームはストーリーの受入基準として機能するいくつかのストーリーテストを作成します。ストーリーテストは、ソフトウェアの回帰スイートに組み合わせて、要件（ユーザーストーリー）からテストへ、そして（実行を通じて）システムの動作へのトレーサビリティを提供できます。ストーリーテストは通常、ブロードスタックテストです。

私は、アプリケーションのUIの直下で動作するテストを指して皮下テストを使用します。これは、アプリケーションの機能テストを行う場合、特にエンドツーエンドの動作をテストしたいが、UI自体を通じてテストするのが困難な場合に特に役立ちます。

閾値テストとは、デプロイメントパイプラインに挿入され、現在のビルドの値を閾値と比較することで測定可能な現象を監視するテストです。現在のビルドの値が閾値を超えると、テストは失敗し、ビルドは失敗します。

単体テストは、ソフトウェア開発で頻繁に話題になり、私がプログラムを作成している間ずっと慣れ親しんできた用語です。しかし、ほとんどのソフトウェア開発用語と同様に、これは非常に曖昧であり、人々が実際よりも厳密に定義されていると考えている場合、混乱が生じる可能性があることがわかります。

ユーザージャーニーテストは、ビジネス向けテストの一種であり、システムを通じた典型的なユーザーの「ジャーニー」をシミュレートするように設計されています。このようなテストは、通常、ある目標を達成するために、ユーザーのシステムとのやり取り全体をカバーします。それらはユースケースの1つのパスとして機能します。