Behavior-driven-development-behavior-test-driven-development
BDD-テスト駆動開発
行動駆動開発に関する参考資料を見ると、「BDDはTDDから派生している」、「BDDおよびTDD」などのフレーズの使用法がわかります。 BDDがどのように生まれたのか、なぜTDDから派生したと言われているのか、BDDとTDDとは何かを知るには、TDDを理解する必要があります。
テストする理由
最初に、テストの基本について説明します。 テストの目的は、構築されたシステムが期待どおりに動作することを確認することです。 次の例を考えてください。
したがって、経験から、導入された時点で欠陥を発見し、すぐに修正することは費用対効果が高いことを学びました。 したがって、開発とテストのすべての段階でテストケースを作成する必要があります。 これは、従来のテスト手法が教えてくれたことであり、テスト初期と呼ばれることがよくあります。
このテストアプローチは、テストがステージの完了後に行われるため、テストラストアプローチと呼ばれます。
テスト最終アプローチの課題
Test-Lastアプローチは、ソフトウェア開発プロジェクトでかなり長い間続いていました。 ただし、実際には、このアプローチでは、特定の段階が完了するまでテストを待機する必要があるため、次の理由で見過ごされがちです-
- ステージの完了の遅延。
- 厳しいスケジュール。
- テストをスキップして、時間通りの配達に焦点を合わせます。
さらに、Test-Lastアプローチでは、開発者が行うことになっている単体テストはしばしばスキップされます。 見つかったさまざまな理由は、開発者の考え方に基づいています-
- 彼らは開発者であり、テスターではありません。
- テストはテスターの責任です。
- これらはコーディングが効率的であり、コードに欠陥はありません。
この結果-
- 提供される製品の品質を損なう。
- テスターのみの品質に対する説明責任を持ちます。
- 欠陥の修正、配達後の高コスト。
- 顧客満足度を獲得できないことは、繰り返しのビジネスの損失を意味し、信頼性に影響を与えます。
これらの要因は、テストに焦点を合わせるために、パラダイムのシフトを求めました。 その結果がテストファーストのアプローチでした。
テストファーストアプローチ
Test-Firstアプローチは、インサイドアウト（コードを記述してからテスト）をアウトサイドイン（テストを記述してからコード）の開発方法に置き換えます。
このアプローチは、以下のソフトウェア開発方法論に組み込まれています（アジャイルでもあります）-
*e* *X* *treme* *P* * rogramming（ *XP* ）。
* * *T* *est* *D* *riven* *D* * evelopment（TDD）。これらの方法論では、開発者はコードモジュールの単一行を記述する前に、コードモジュールの単体テストを設計および記述します。 その後、開発者は単体テストに合格することを目標にコードモジュールを作成します。 したがって、これらの方法論では、ユニットテストを使用して開発を推進しています。
目標はテストに基づく開発であることに注意する基本的なポイント。
赤緑リファクタリングサイクル
テスト駆動開発は、単体テストに基づいたコードの開発に使用されます。
- ステップ1 *-作成するコードモジュールを検討します。
- ステップ2 *-テストを書く
- ステップ3 *-テストを実行します。
コードはまだ記述されていないため、テストは失敗します。 そのため、ステップ2は通常、テストの書き込みと呼ばれます。
- ステップ4 *-テストに合格するための最小限のコードを記述します。
- ステップ5 *-すべてのテストを実行して、すべてがテストに合格することを確認します。 このステップを容易にするために、単体テストが自動化されています。
- ステップ6 *-リファクタリング。
- ステップ7 *-次のコードモジュールに対してステップ1からステップ6を繰り返します。
各サイクルは非常に短く、通常の時間には多くのサイクルが含まれている必要があります。
これは、一般に Red-Green-Refactor サイクルとしても知られています。
- 赤-失敗するテストの作成。
- 緑-テストに合格するためのコードの記述。
- リファクタリング-重複を削除し、コードを許容可能な標準に改善します。
TDDプロセスステップ
TDDプロセスの手順を以下に示します。
TDDの利点
テスト駆動開発の利点または利点は次のとおりです-
- 開発者は、最初に、目的の結果がどうあるべきか、そしてコードを作成する前にテストする方法を理解する必要があります。
- コンポーネントのコードは、テストに合格し、コードがリファクタリングされたときにのみ終了します。 これにより、開発者が次のテストに進む前にテストとリファクタリングが保証されます。
- ユニットテストのスイートは各リファクタリングの後に実行されるため、各コンポーネントがまだ動作しているというフィードバックは一定です。
- ユニットテストは、常にデータに応じた生きたドキュメントとして機能します。
- 欠陥が見つかった場合、開発者はその欠陥を明らかにするテストを作成し、テストに合格して欠陥が修正されるようにコードを修正します。 これにより、デバッグ時間が短縮されます。 他のすべてのテストも実行され、それらが合格すると、既存の機能が破損しないことが保証されます。
- 開発者はいつでも設計上の決定とリファクタリングを行うことができ、テストの実行によりシステムが引き続き機能していることが保証されます。 これにより、ソフトウェアが保守可能になります。
- 開発者は、変更が既存の機能に影響を与える場合、テストを実行することで同じことが明らかになり、欠陥をすぐに修正できるため、変更を行う自信があります。
- 連続する各テスト実行で、以前のすべての不具合修正も検証され、同じ不具合の繰り返しが削減されます。
- ほとんどのテストは開発中に行われるため、配信前のテストは短縮されます。
TDDの欠点
開始点は、システムの動作を説明するユーザーストーリーです。 したがって、開発者はしばしば次の質問に直面します-
- いつテストする？
- 何をテストしますか？
- 仕様が満たされているかどうかを知る方法は？
- コードはビジネス価値をもたらしますか？
TDDについての誤解
以下の誤解が業界に存在し、明確化が必要です。
| Misconception | Clarification |
|---|---|
| TDD is all about testing and test automation. | TDD is a development methodology using Test-First approach. |
| TDD does not involve any design. | TDD includes critical analysis and design based on the requirements. The design emerges during development. |
| TDD is only at Unit level. | TDD can be used at the integration and system levels. |
| TDD cannot be used by traditional testing projects. | TDD became popular with Extreme Programming and is being used in other Agile methodologies. However, it can be used in traditional testing projects as well. |
| TDD is a tool. |
TDD is a development methodology, and after every new Unit Test passes, it is added to the Automation Test Suite as all the tests need to be run whenever a new code is added or existing code is modified and also after every refactoring. したがって、TDDをサポートするテスト自動化ツールは、このプロセスを容易にします。 |
| TDD means handing Acceptance tests to the developers. | TDD does not mean handing Acceptance Tests to the developers. |
受け入れTDD
受け入れテスト駆動開発（ATDD）は、開発の初期段階で、ユーザーストーリーの作成中に受け入れ基準と受け入れテストを定義します。 ATDDは、顧客、開発者、テスター間のコミュニケーションと共通理解に焦点を当てています。
ATDDのキープラクティスは次のとおりです-
- ドメインについての共通の理解を構築するために、実世界のシナリオについて話し合います。
- これらのシナリオを使用して、受け入れ基準に到達します。
- 受け入れテストを自動化します。
- これらのテストに開発の焦点を合わせます。
- テストを実際の仕様として使用して、変更を容易にします。
ATDDを使用する利点は次のとおりです-
- 要件は明確であり、機能的なギャップはありません。
- 開発者が予見する特殊なケースを理解している人もいます。
- 受け入れテストは開発をガイドします。
TDD対BDD
ダンノースによると、プログラマは通常、テスト駆動開発の実行中に次の問題に直面します-
- どこから始めれば
- テストするものとテストしないもの
- 一度にテストする量
- 彼らのテストと呼ぶもの *テストが失敗する理由を理解する方法
これらすべての問題の解決策は、行動駆動型開発です。 これは、確立されたアジャイルプラクティスから発展し、アジャイルソフトウェア配信に新しい、チームにとってそれらをよりアクセスしやすく効果的にするように設計されています。 時間が経つにつれて、BDDはアジャイル分析および自動化された受け入れテストの全体像を網羅するように成長しました。
TDDとBDD* の主な*違いは次のとおりです-
- TDDは、ソフトウェアの動作を説明します。
- 一方、BDD-
- エンドユーザーがソフトウェアを使用する方法を説明します。
- コラボレーションとコミュニケーションを促進します。
- システムの動作の例を強調します。
- 例から導き出された実行可能な仕様を目指します
