テストピラミッド

テストピラミッドとは、バランスの取れたポートフォリオを作成するために、さまざまな種類の自動テストをどのように使用すべきかを考える方法です。重要な点は、GUI を介して実行される高レベルの広範囲テストよりも、低レベルの単体テストをはるかに多く実施する必要があるということです。

私のキャリアの多くにおいて、テストの自動化とは、ユーザーインターフェースを介してアプリケーションを駆動するテストを意味していました。このようなツールは、多くの場合、アプリケーションとのインタラクションを記録し、そのインタラクションを再生して、アプリケーションが同じ結果を返すことを確認する機能を提供します。このようなアプローチは、最初はうまく機能します。テストの記録は簡単で、プログラミングの知識がない人でもテストを記録できます。

しかし、この種のアプローチはすぐに問題にぶち当たり、アイスクリームコーンになってしまいます。UI を介したこのようなテストは時間がかかり、ビルド時間を増加させます。多くの場合、テスト自動化ソフトウェアのインストール済みライセンスが必要になるため、特定のマシンでしか実行できません。通常、これらは適切なデプロイメントパイプラインに配置するためのスクリプトによって監視される「ヘッドレス」モードで簡単に実行することはできません。

最も重要なことは、このようなテストは非常に脆いということです。システムの機能強化によって、このようなテストの多くが簡単に壊れてしまい、再記録が必要になる可能性があります。この問題は、レコード再生ツールを放棄することで軽減できますが、テストの作成が難しくなります。[1] 優れたプラクティスに従って記述したとしても、エンドツーエンドテストは非決定性問題が発生しやすく、テストへの信頼が損なわれる可能性があります。要するに、UI を介してエンドツーエンドで実行されるテストは、脆く、作成に費用がかかり、実行に時間がかかります。そのため、ピラミッドは、従来の GUI ベースのテストよりも、単体テストによる自動テストをはるかに多く実行する必要があると主張しています。[2]

ピラミッドはまた、アプリケーションのサービス層を介して動作する中間層のテスト、私が皮下テストと呼ぶものを主張しています。これらは、エンドツーエンドテストの多くの利点を提供しながら、UI フレームワークを扱う多くの複雑さを回避できます。Web アプリケーションでは、これは API 層を介したテストに対応し、ピラミッドの最上位の UI 部分はSeleniumや Sahi のようなものを使用するテストに対応します。

テストピラミッドはアジャイルテストの分野でよく話題になりますが、その中心となるメッセージは健全ですが、バランスの取れたテストポートフォリオの構築については、さらに多くのことが言えます。よくある問題は、チームがエンドツーエンドテスト、UI テスト、顧客向けテストの概念を混同することです。これらはすべて直交する特性です。たとえば、リッチな JavaScript UI は、その UI 動作のほとんどをJasmineのようなものを使用して JavaScript 単体テストでテストする必要があります。複雑なビジネスルールセットは、顧客向けの形式でテストをキャプチャできますが、単体テストと同様に、関連するモジュールでのみ実行されます。

私は常に、高レベルのテストはテスト防御の第 2 のラインとして存在すると主張しています。高レベルのテストで障害が発生した場合、機能コードにバグがあるだけでなく、単体テストが欠落しているか正しくないことになります。そのため、高レベルのテストによって明らかになったバグを修正する前に、単体テストでバグを再現することをお勧めします。そうすれば、単体テストによってバグが確実に修正されます。