テスト駆動開発

テスト駆動開発では、実装前にテストを作成すると、プライベートメソッドをテストするか、パブリックインターフェースのみをテストするかという問題が生じます。この選択は、テストコードと本番コードの両方の設計に影響を与えます。

テスト駆動開発（TDD）は、迅速なレッド・グリーン・リファクタリングサイクルを実現するために、主に単体テストに依存しています。これらのテストは、プロセス境界、ネットワーク接続、外部依存関係を回避することで、高速に実行されます。TDDの実践者は、コンポーネント間の相互作用を検証するために統合テストも作成しますが、これらの実行速度の遅いテストは、より頻繁に実行される単体テストとは別に管理されます。複数の統合モジュールを一緒にテストすると、障害の原因を特定することがより困難になるという問題もあります。

開発中のコードが外部依存関係に依存している場合、TDD は高速で分離された単体テストを維持するためにテスト ダブルの使用を推奨します。 ^{[ 13 ]}一般的なアプローチは、インターフェースを使用して外部依存関係を分離し、テスト目的でテスト ダブルを実装することです。

テストダブルは実際の外部コンポーネントとの関連性を証明できないため、TDDの実践者は適切なレベルでユニットテストに加えて統合テストを実施します。実行速度と信頼性を高めるため、ユニットレベルでのテストを最大化し、より上位レベルでの時間のかかるテストを最小限に抑えます。

TDD（テスト駆動開発）では、ユニットは一般的にクラス、またはモジュールと呼ばれる関連関数のグループとして定義されます。ユニットを比較的小さく保つことで、以下のような重要な利点が得られるとされています。

• デバッグ作業の軽減 – テストの失敗が検出された場合、単位が小さいほどエラーの追跡が容易になります。
• 自己文書化テスト – 小さなテストケースは読みやすく理解しやすい。^{[ 11 ]}

テスト駆動開発の高度な実践により、受け入れテスト駆動開発(ATDD) や例による仕様作成につながり、顧客が指定した基準が受け入れテストに自動化され、それが従来の単体テスト駆動開発 (UTDD) プロセスを推進します。^{[ 14 ]}このプロセスにより、顧客はソフトウェアが要件を満たしているかどうかを判断する自動化されたメカニズムを持つことができます。ATDD では、開発チームは受け入れテストという特定の目標を満たすことができるため、各ユーザー ストーリーから顧客が本当に求めているものに継続的に集中することができます。

テストケースを効果的にレイアウトすることで、必要なすべてのアクションが確実に完了し、テストケースの可読性が向上し、実行の流れがスムーズになります。一貫性のある構造は、自己文書化可能なテストケースの構築に役立ちます。テストケースで一般的に用いられる構造は、（1）セットアップ、（2）実行、（3）検証、（4）クリーンアップです。

• セットアップ：被試験ユニット（UUT）またはテストシステム全体を、テストを実行するために必要な状態にします。
• 実行：テスト対象（UUT）をトリガー／駆動して目標動作を実行させ、戻り値や出力パラメータなどのすべての出力を取得します。この手順は通常非常に簡単です。
• 検証：テスト結果が正しいことを確認します。これらの結果には、実行中に取得された明示的な出力や、被試験機器（UUT）の状態変化が含まれる場合があります。
• クリーンアップ: UUT またはテストシステム全体をテスト前の状態に復元します。この復元により、このテストの直後に別のテストを実行できるようになります。場合によっては、テスト失敗分析のための情報を保持するために、クリーンアップはテストのセットアップ実行の直前に開始する必要があります。^{[ 11 ]}

個人が従うべきベストプラクティスとしては、共通のセットアップおよびティアダウンロジックを適切なテストケースで使用されるテストサポートサービスに分離すること、各テストオラクルがテストの検証に必要な結果のみに焦点を当てるようにすること、および非リアルタイムオペレーティングシステムでの実行に対する許容範囲を設けるように時間関連のテストを設計することなどが挙げられます。実行遅延に対して 5～10% のマージンを設ける一般的なプラクティスは、テスト実行における偽陰性の可能性を減らします。また、テストコードは本番コードと同じように扱うことが推奨されます。テストコードは、ポジティブケースとネガティブケースの両方で正しく動作し、長期間にわたって動作し、読みやすく保守しやすいものでなければなりません。チームは集まってテストとテストプラクティスをレビューし、効果的なテクニックを共有し、悪い習慣を見つけることができます。^{[ 15 ]}

• テストケースが、以前に実行されたテストケースによって操作されたシステム状態に依存すること（つまり、ユニットテストは常に既知の事前構成された状態から開始する必要があります）。
• テストケース間の依存関係。テストケースが相互に依存しているテストスイートは、脆弱で複雑です。実行順序は想定すべきではありません。初期テストケースやUUTの構造を単純にリファクタリングすると、関連するテストにますます広範囲にわたる影響が連鎖的に発生します。
• 相互依存テスト。相互依存テストは、連鎖的な偽陰性を引き起こす可能性があります。初期のテストケースで失敗すると、UUTに実際の欠陥が存在しない場合でも、後のテストケースが失敗し、欠陥分析とデバッグの手間が増加します。
• 正確な実行、タイミング、またはパフォーマンスをテストします。
• 「全知のオラクル」を構築する。必要以上に検査を行うオラクルは、コストがかさみ、時間の経過とともに脆弱になる。この非常に一般的な誤りは、複雑なプロジェクト全体に微妙ながらも広範囲にわたる時間の浪費を引き起こすため危険である。^{[ 15 ]}
• テスト実装の詳細。
• 実行時間の長いテスト。

テスト駆動開発は、受け入れテスト駆動開発(ATDD) と関連していますが、異なります。^{[ 16 ]} TDD は主に、一連の操作を正しく実行する適切に記述されたコード単位 (関数、クラス、またはモジュール) を作成するのに役立つ開発者ツールです。ATDD は、要件が適切に定義されていることを保証するための顧客、開発者、およびテスター間のコミュニケーションツールです。TDD にはテスト自動化が必要です。ATDD には必要ありませんが、自動化は回帰テストに役立ちます。コード単位が要件の一部を実装するため、TDD で使用されるテストは ATDD テストから派生することがよくあります。ATDD テストは顧客が読みやすい必要があります。TDD テストは読みやすい必要はありません。

BDD（ビヘイビア駆動開発）は、TDDとATDDのプラクティスを組み合わせたものです。^{[ 17 ]} テストを最初に書くというプラクティスを含みますが、実装単位をテストするテストではなく、動作を記述するテストに焦点を当てています。JBehave 、Cucumber、Mspec、Specflowなどのツールは、プロダクトオーナー、開発者、テストエンジニアが一緒に動作を定義し、それを自動テストに変換できる構文を提供します。

開発者は、コンピュータ支援テストフレームワーク（一般的にxUnitと総称される。これは1998年に作成されたSUnitから派生したものである）を使用して、テストケースを作成し、自動的に実行することができます。xUnitフレームワークは、アサーションスタイルのテスト検証機能と結果レポート機能を提供します。これらの機能は、実行検証の負担を独立した後処理アクティビティからテスト実行に含まれるアクティビティに移すため、自動化にとって非常に重要です。これらのテストフレームワークが提供する実行フレームワークにより、すべてのシステムテストケースまたはさまざまなサブセットを他の機能とともに自動的に実行できます。^{[ 18 ]}

テストフレームワークは、1987年に作成された言語非依存のTest Anything Protocolで出力された単体テスト結果を受け入れることができる。

複雑なシステムには、さまざまな要件を満たすアーキテクチャが必要です。これらの要件の重要なサブセットには、システムの完全かつ効果的なテストをサポートすることが含まれます。効果的なモジュール設計により、効果的なTDDに不可欠な特性を共有するコンポーネントが生まれます。

• 高い凝集性により、各ユニットは関連する一連の機能を提供し、それらの機能のテストの維持が容易になります。
• 低結合により、各ユニットを個別に効果的にテストすることが可能です。
• 公開インターフェースはコンポーネントへのアクセスを制限し、テストの接点として機能することで、テストの作成を容易にし、テストユニットと本番ユニットの構成間の最高の忠実度を保証します。

効果的なモジュール型アーキテクチャを構築するための重要な手法はシナリオモデリングであり、これは一連のシーケンスチャートを作成し、それぞれが単一のシステムレベルの実行シナリオに焦点を当てます。シナリオモデルは、特定の刺激に対するコンポーネント間の相互作用の戦略を作成するための優れた手段となります。これらのシナリオモデルはそれぞれ、コンポーネントが提供しなければならないサービスまたは機能の豊富な要件セットとして機能し、これらのコンポーネントとサービスが相互作用する順序も規定します。シナリオモデリングは、複雑なシステムのTDDテストの構築を大幅に容易にすることができます。^{[ 11 ]}

大規模なシステムでは、コンポーネントの品質が低いことによる影響は、相互作用の複雑さによって増幅されます。この増幅効果により、大規模プロジェクトではTDDのメリットがより早く現れます。しかし、テスト全体の複雑さ自体が問題となり、潜在的なメリットを損なう可能性があります。単純に聞こえるかもしれませんが、重要な最初のステップは、テストコードも重要なソフトウェアであり、本番コードと同じ厳密さで作成および保守されるべきであるという認識を持つことです。

複雑なシステム内でテストソフトウェアのアーキテクチャを作成および管理することは、コア製品のアーキテクチャと同様に重要です。テストドライバは、UUT、テストダブル、およびユニットテストフレームワークと相互作用します。^{[ 11 ]}

TDD は、開発者が自動化されたテストを繰り返し実行することで、開発中に迅速なフィードバックを提供できます。これにより、回帰バグが導入された直後に検出しやすくなり、動作変更に対するセーフティネットを提供することでリファクタリングをサポートできます。 ^{[ 24 ]}テストは対応する本番コードの前に記述されるため、開発者は実装前にコードの望ましい動作とインターフェースを考慮する必要があります。これにより、特に実装の詳細ではなく公開動作に対してテストが記述されている場合、より小さなコード単位、疎結合、およびより明確なインターフェースが促進されます。^{[ 24 ] [ 21 ]}

TDDでは、開発の副産物として一連の自動テストが生成される傾向があります。このようなテストは、変更がマージまたはリリースされる前に頻繁にテストされる継続的インテグレーションのワークフローで役立ちます。この意味で、TDDは後々の変更に対する信頼性を高める可能性がありますが、単体テストに合格したからといって、ソフトウェアが正しいことが証明されるわけではありません。^{[ 19 ] [ 20 ]}

TDDは、他のソフトウェアテスト手法の代替となるものではありません。TDDは一般的に単体テストを通じて実施されるため、ユーザーインターフェース、データベース、分散システム、ハードウェア、タイミング、セキュリティ特性、コンポーネント間の相互作用などに依存する動作を十分にテストできない場合があります。これらの領域では、多くの場合、追加の統合テスト、システムテスト、受け入れテスト、ユーザビリティテスト、またはその他の専門的なテスト手法が必要となります。

TDD（テスト駆動開発）で作成されたテストは、本番コードと同じ誤解を抱えている可能性があります。開発者が要件を誤って解釈した場合、テストと実装の両方に同じ誤った前提が組み込まれ、ソフトウェアに問題があるにもかかわらずテストが合格してしまうことがあります。そのため、テストが不完全であったり、範囲が狭すぎたり、外部から見える動作ではなく実装の詳細に焦点を当てていたりすると、多数のテストが合格したとしても、誤った安心感を生み出す可能性があります。

自動テストはメンテナンスコストも生み出します。内部実装の詳細に密接に結合しているテスト、過剰なモックを使用しているテスト、脆弱なタイミング仮定に依存しているテスト、または重複したセットアップコードを含むテストは、メンテナンスが困難になる可能性があります。^{[ 25 ]}特に複雑なブラウンフィールドタスクや自動テストの経験が限られているプロジェクトなど、一部の状況では、テストの作成とメンテナンスに必要な時間が短期的な生産性を低下させる可能性があります。^{[ 22 ] [ 20 ]}