ソフトウェアテストガイド

2002年にXP/Agile Universeのワークショップに参加していたとき、「Exampleによる仕様」というフレーズが、XPにおけるテストの役割の一つを説明する方法として心に響きました。

テスト駆動開発（TDD）は、テストを記述することでソフトウェア開発をガイドするソフトウェアを構築するための手法です。これは、1990年代後半にKent Beckによってエクストリームプログラミングの一部として開発されました。本質的には、3つの簡単なステップを繰り返し実行します

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

「テストピラミッド」は、ソフトウェアテストを異なる粒度のバケットにグループ化するように指示するメタファーです。また、これらのグループのそれぞれにどれくらいのテストが必要かについてのアイデアも示します。テストピラミッドの概念はしばらく前から存在していますが、チームはそれを適切に実践するのに苦労しています。この記事では、テストピラミッドの元の概念を再検討し、これを実践する方法を示します。ピラミッドのさまざまなレベルでどのような種類のテストを探すべきかを示し、これらを実装する方法の実例を示します。

ここ数年、サービスベースのアーキテクチャは、より小さく、より焦点を絞った「マイクロ」サービスへとシフトしています。このアプローチには、各コンポーネントを独立してデプロイ、スケーリング、保守できる機能や、複数のチーム間で開発を並行化できるなど、多くの利点があります。ただし、これらの追加のネットワークパーティションが導入されると、モノリシックなインプロセスアプリケーションに適用されていたテスト戦略を再検討する必要があります。ここでは、複数の独立してデプロイ可能なコンポーネントの追加のテストの複雑さを管理するための多くのアプローチと、複数のチームがそれぞれ異なるサービスの保護者として行動しているにもかかわらず、テストとアプリケーションを正確に維持する方法について説明する予定です。

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

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

広範囲テストは、大規模アプリケーションのほとんどの部分をテストするテストです。これは、エンドツーエンドテストまたはフルスタックテストとも呼ばれます。コンポーネントテストとは対照的で、システムの一部のみをテストします。

統合テストは、独立して開発されたソフトウェアユニットが相互に接続されたときに正しく動作するかどうかを判断します。この用語は、ソフトウェア業界の拡散した標準によっても曖昧になっているため、私の文章で使用することを警戒してきました。特に、多くの人が統合テストは必然的に範囲が広いと想定していますが、より狭い範囲でより効果的に行うことができます。

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

テストダブルを使用する最も一般的なケースの1つは、外部サービスと通信している場合です。通常、このようなサービスは別のチームによって保守されており、ネットワークが遅く、信頼性が低い場合や、それ自体が信頼できない場合があります。そのため、テストダブルは便利で、独自のテストが遅く信頼性が低くなるのを防ぎます。ただし、ダブルに対してテストを行うと、ダブルが外部サービスの正確な表現であるかどうか、および外部サービスが契約を変更した場合に何が起こるかという問題が常に発生します。

コンポーネントテストは、テスト対象のシステムの一部に、テストされるソフトウェアの範囲を制限するテストです。これは、できる限り多くのシステムをテストするように意図された広範囲テストとは対照的です。

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

私は皮下テストを、アプリケーションのUIのすぐ下で動作するテストを意味するために使用しています。これは、アプリケーションの機能テストを行う場合に特に価値があります。エンドツーエンドの動作をテストしたいが、UI自体を介してテストするのが難しい場合です。

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

Gerard Meszarosは、さまざまなXunitフレームワークを使用するためのパターンをキャプチャする本を執筆中です。彼が遭遇した厄介なことの1つは、スタブ、モック、フェイク、ダミー、およびテストのためにシステムの一部をスタブアウトするために使用するその他のさまざまな名前です。これに対処するために、彼は独自の語彙を考案しました。これはさらに広める価値があると思います。

XUnitとは、ソフトウェア開発者の間で広く知られるようになったテストフレームワークの総称です。この名前は、広く知られるようになった最初のテストフレームワークであるJUnitに由来しています。

「モックオブジェクト」という用語は、テストのために実際のオブジェクトを模倣する特殊なオブジェクトを指す一般的な用語になりました。現在、ほとんどの言語環境には、モックオブジェクトを簡単に作成できるフレームワークがあります。しかし、しばしば認識されていないのは、モックオブジェクトが特殊なテストオブジェクトの一形態に過ぎず、異なるスタイルのテストを可能にするということです。この記事では、モックオブジェクトがどのように機能するか、どのように振る舞いの検証に基づくテストを促進するか、そしてモックオブジェクトを中心とするコミュニティがどのようにそれらを使用して異なるスタイルのテストを開発するかについて説明します。

今世紀に入り、プログラマーが自分のコードのテストを責任を持って行う、プログラマーテストが著しく増加しました。これにより、バグが減少し、API設計について考えやすくなり、リファクタリングが可能になることがわかりました。これを実現する上で大きな役割を果たしているのは、ケント・ベックとエリック・ガンマの研究から生まれた、xUnitというシンプルなテストフレームワークのファミリーです。しかし、xUnitはシンプルなツールであるものの、効果的に使用するには経験とスキルが必要です。ジェラード・メスザロスは、これらのツールと、ソフトウェア設計手法を学習する上でパターンを使用するというアイデアを早期に採用しました。これは、テストの使用方法についてコミュニケーションするのに役立つ語彙と、経験豊富な実践者が知識を新しい世代に伝えるための基盤を提供します。

2014年初頭に2つのコンピュータセキュリティ上の欠陥が発見されました。Appleの「goto fail」バグとOpenSSLの「Heartbleed」バグです。どちらも、広範囲かつ深刻なセキュリティ障害を引き起こす可能性があり、その全容は決して分からないかもしれません。その深刻さを考えると、ソフトウェア開発の専門家は、将来的にこれらの種類の欠陥を防止する能力を向上させるために、どのように検出できたかを考察することが重要です。この記事では、単体テストが果たす可能性のある役割について検討し、単体テスト、そしてより重要な単体テスト文化が、これらの特定のバグをどのように特定できたかを示します。さらに、そのような文化のコストとメリットについて検討し、Googleでそのような文化をどのように浸透させたかについて説明します。

自動回帰スイートは、ソフトウェアプロジェクトにおいて重要な役割を果たし、本番環境での欠陥を減らすためだけでなく、進化的設計にも不可欠です。開発チームと話をしていると、非決定的なテスト、つまり合格したり失敗したりするテストの問題をよく耳にします。制御されないまま放置すると、非決定的なテストは、自動回帰スイートの価値を完全に破壊する可能性があります。この記事では、非決定的なテストに対処する方法の概要を説明します。最初は隔離が他のテストへの損害を軽減するのに役立ちますが、それでもすぐに修正する必要があります。したがって、非決定性の一般的な原因、つまり、隔離の欠如、非同期の動作、リモートサービス、時間、およびリソースリークに対する対処法について説明します。

私のキャリアがフルタイムの著述業に転換するにつれて、私は日々のソフトウェア開発の現実から自分自身がかけ離れてしまうのではないかと、しばしば心配しています。私は他の著名人が現実とのつながりを失うのを見てきたので、同じ運命を恐れています。これに対する私の最大の抵抗源はThoughtworksであり、それは私が地に足を着けていられるように定期的な現実を投与してくれる役割を果たしています。

Thoughtworksは、現場からのアイデアの源泉としても機能しており、私は同僚が発見し開発した有用なものについて書くのを楽しんでいます。通常、これらは役立つアイデアであり、私の読者の中には使える人がいるだろうと思っています。今日の私のトピックは、それほど楽しいものではありません。それは問題であり、私たちには答えがありません。

時々、テストカバレッジ（コードカバレッジとも呼ばれる）の目標値を尋ねたり、自分のカバレッジレベルを誇らしげに述べたりする人がいます。そのような発言はポイントを見失っています。テストカバレッジは、コードベースのテストされていない部分を見つけるための便利なツールです。テストカバレッジは、テストの良さを数値で示すものとしてはほとんど役に立ちません。

テストインパクト分析（TIA）は、ビルドのテスト自動化フェーズを高速化する最新の方法です。これは、ソースコードのコールグラフを分析して、本番コードを変更した後でどのテストを実行する必要があるかを把握することによって機能します。マイクロソフトは、このアプローチについて広範な作業を行ってきましたが、開発チームが非常に安価で役立つものを実装することも可能です。

Ruby on Railsの作成者であるDavid Heinemeier Hanssonは、RailsConfで基調講演を行い、TDDは死んだと宣言しました。これは、Railsとより広範なソフトウェア開発コミュニティの両方で予想通り大きな論争を引き起こしました。また、David、Kent、そして私自身の間で興味深い会話にもつながりました。これらの会話は非常に興味深いので、他の人も見てみたいと思うかもしれないと考え、ソフトウェア開発におけるTDDの役割について話し合う一連のビデオハングアウトを録画しました。

Webページに対してテストを作成するときは、リンクをクリックしたり、何が表示されているかを判断したりするために、そのWebページ内の要素を参照する必要があります。ただし、HTML要素を直接操作するテストを作成すると、UIの変更に対してテストが脆くなります。ページオブジェクトは、HTMLページまたはフラグメントをアプリケーション固有のAPIでラップし、HTMLを掘り下げなくてもページ要素を操作できるようにします。

テストダブルを使用する典型的なケースの1つは、リモートサービスを呼び出すときです。リモートサービスは通常遅く、信頼性が低いため、ダブルを使用することは、テストをより速く安定させるための良い方法です。

一部のプログラム要素は、本質的にテストが困難、あるいは不可能です。したがって、これらの要素のロジックはバグが発生しやすく、進化が困難です。この問題を軽減するために、テストが困難な要素からできるだけ多くのロジックを、コードベースのよりフレンドリーな部分に移動します。テストできないオブジェクトを謙虚にすることで、それらが悪意のあるバグを隠す可能性を減らします。

最新のモックツールがレガシーコードを扱う能力に与えるプラスの効果と、これらのツールを使用することによる潜在的なマイナスの影響。

コードで現在の日付または時刻を取得する必要がある場合は、そのデータのシステムルーチンに直接アクセスしないでください。「現在の日付/時刻」を特定の値に設定してオーバーライドできるようにするラッパー形式を配置します。これはテストを簡素化するために重要です。

オブジェクトマザーとは、テストで使用するサンプルオブジェクトの作成を支援するためにテストで使用される一種のクラスです。

私は古いメモを調べていたところ、リッチ・ガーザニティが私に教えてくれたシンプルで便利なヒントを見つけました。

従来、QAはソフトウェアを本番環境にリリースする前にテストして、リリースする準備ができているかどうかを確認することに重点を置いています。しかし、近年、最新のQA組織は、本番環境で実行されているソフトウェアにも注目しています。ログやその他の監視ツールを分析することにより、開発組織に強調する品質問題を見つけます。このアプローチは、継続的デリバリーを使用してソフトウェアの新しいバージョンを迅速かつ確実に本番環境に投入する組織で特に効果を発揮します。

探索的テストとは、学習、テスト設計、およびテスト実行の迅速なサイクルを重視するテストスタイルです。ソフトウェアが事前に記述されたテストスクリプトに準拠していることを検証しようとするのではなく、探索的テストではソフトウェアの特性を探索し、合理的な動作または失敗として分類される発見を提起します。

ソフトウェアシステムの可観測性は常に価値があり、クラウドとマイクロサービスの時代にはさらに重要になっています。しかし、システムに追加する可観測性は、本質的にかなり低レベルで技術的なものであり、多くの場合、さまざまなロギング、インストルメンテーション、分析フレームワークへの冗長で冗長な呼び出しをコードベースに散らかす必要があるようです。この記事では、この混乱を解消し、ビジネスに関連する可観測性をクリーンでテスト可能な方法で追加できるようにするパターンについて説明します。

合成監視（セマンティック監視とも呼ばれます）は、アプリケーションの自動テストのサブセットを、本番稼働中のシステムに対して定期的に実行します。その結果は監視サービスにプッシュされ、障害が発生した場合にアラートがトリガーされます。この手法は、自動テストと監視を組み合わせることで、本番環境におけるビジネス要件の失敗を検出します。