BDD-テスト駆動開発
ビヘイビア駆動開発に関する参考資料を見ると、「BDDはTDDから派生している」、「BDDとTDD」などのフレーズの使用法がわかります。BDDがどのように生まれたのか、なぜそれがTDDから派生したと言われるのか、そしてBDDとTDDとは何かを知るには、TDDを理解する必要があります。
なぜテストするのですか？
まず、テストの基本について説明します。テストの目的は、構築されたシステムが期待どおりに機能していることを確認することです。次の例を考えてみましょう。
したがって、経験から、欠陥が発生したときにそれを発見し、すぐに修正することが費用効果が高いことがわかりました。したがって、開発とテストのすべての段階でテストケースを作成する必要があります。これは、私たちの伝統的なテスト手法が私たちに教えてくれたことであり、しばしばテストアーリーと呼ばれます。
このテストアプローチは、ステージの完了後にテストが行われるため、テストラストアプローチと呼ばれます。
テストラストアプローチの課題
Test-Lastアプローチは、ソフトウェア開発プロジェクトでかなり長い間続いていました。ただし、実際には、このアプローチでは、テストは特定の段階が完了するまで待機する必要があるため、次の理由で見落とされることがよくあります。
ステージの完了の遅れ。
タイトなタイムスケジュール。
テストをスキップして、時間通りに配達することに焦点を合わせます。
さらに、Test-Lastアプローチでは、開発者によって実行されるはずのユニットテストがスキップされることがよくあります。見つかったさまざまな理由は、開発者の考え方に基づいています-
彼らは開発者であり、テスターではありません。
テストはテスターの責任です。
それらはコーディングにおいて効率的であり、それらのコードには欠陥がありません。
これにより、-
提供される製品の品質を損なう。
テスターのみの品質に対する説明責任を持つ。
欠陥の修正、納品後の高コスト。
顧客満足度が得られないことは、リピートビジネスの喪失を意味し、信頼性に影響を及ぼします。
これらの要因は、テストに焦点を合わせるために、パラダイムの転換を要求しました。その結果がテストファーストアプローチでした。
テストファーストアプローチ
Test-Firstアプローチは、インサイドアウト（コードを記述してからテスト）をアウトサイドイン（テストを記述してからコード）の開発方法に置き換えます。
このアプローチは、次のソフトウェア開発方法論（アジャイルでもあります）に組み込まれています-
eXトレム Programming（XP）。
TEST（東部基準時 Dリベン D開発（TDD）。
これらの方法論では、開発者は、コードモジュールの1行を記述する前に、コードモジュールの単体テストを設計および記述します。次に、開発者は単体テストに合格することを目的としてコードモジュールを作成します。したがって、これらの方法論では、単体テストを使用して開発を推進します。
目標はテストに基づく開発であることに注意する基本的なポイント。
赤-緑-リファクタリングサイクル
テスト駆動開発は、単体テストによって導かれるコードを開発するために使用されます。
Step 1 −作成するコードモジュールについて考えてみます。
Step 2 −テストを書く
Step 3 −テストを実行します。
コードがまだ書かれていないため、テストは失敗します。したがって、ステップ2は通常、失敗するテストの作成と呼ばれます。
Step 4 −テストに合格するために可能な最小限のコードを記述します。
Step 5−すべてのテストを実行して、すべてがまだ合格していることを確認します。ユニットテストは、このステップを容易にするために自動化されています。
Step 6 −リファクタリング。
Step 7 −次のコードモジュールについて、ステップ1からステップ6を繰り返します。
各サイクルは非常に短くする必要があり、通常の1時間には多くのサイクルが含まれている必要があります。
これは一般に Red-Green-Refactor サイクル、ここで-
Red −失敗するテストを作成する。
Green −テストに合格するためのコードを書く。
Refactor −重複を削除し、コードを許容可能な標準に改善します。
TDDプロセスステップ
TDDプロセスのステップを以下に示します。
TDDの利点
テスト駆動開発の利点または利点は次のとおりです。
開発者は、コードを作成する前に、最初に、望ましい結果がどうあるべきか、そしてそれをテストする方法を理解する必要があります。
コンポーネントのコードは、テストに合格してコードがリファクタリングされたときにのみ終了します。これにより、開発者が次のテストに進む前に、テストとリファクタリングが保証されます。
ユニットテストのスイートは各リファクタリングの後に実行されるため、各コンポーネントがまだ機能しているというフィードバックは一定です。
ユニットテストは、常にデータに依存する生きたドキュメントとして機能します。
欠陥が見つかった場合、開発者はその欠陥を明らかにするためのテストを作成し、テストに合格して欠陥が修正されるようにコードを変更します。これにより、デバッグ時間が短縮されます。他のすべてのテストも実行され、それらが合格すると、既存の機能が壊れていないことが保証されます
開発者はいつでも設計上の決定とリファクタリングを行うことができ、テストを実行することでシステムが引き続き機能していることを確認できます。これにより、ソフトウェアが保守可能になります。
変更が既存の機能に影響を与える場合、テストを実行することで同じことが明らかになり、欠陥をすぐに修正できるため、開発者は変更を加える自信があります。
連続する各テスト実行で、以前のすべての欠陥修正も検証され、同じ欠陥の繰り返しが減少します。
ほとんどのテストは開発中に行われるため、納品前のテストは短縮されます。
TDDのデメリット
出発点は、システムの動作を説明するユーザーストーリーです。したがって、開発者はしばしば次の質問に直面します-
いつテストしますか？
何をテストしますか？
仕様が満たされているかどうかを知る方法は？
コードはビジネス価値を提供しますか？
TDDに関する誤解
以下の誤解が業界に存在し、説明が必要です。
| 誤解 | 明確化 |
|---|---|
| TDDは、テストとテスト自動化がすべてです。 | TDDは、テストファーストアプローチを使用した開発方法論です。 |
| TDDには設計は含まれていません。 | TDDには、要件に基づいた重要な分析と設計が含まれています。デザインは開発中に現れます。 |
| TDDはユニットレベルのみです。 | TDDは、統合レベルおよびシステムレベルで使用できます。 |
| TDDは、従来のテストプロジェクトでは使用できません。 | TDDはエクストリームプログラミングで普及し、他のアジャイル手法で使用されています。ただし、従来のテストプロジェクトでも使用できます。 |
| TDDはツールです。 | TDDは開発方法論であり、新しい単体テストに合格するたびに、新しいコードが追加されたり既存のコードが変更されたりするたびに、またすべてのリファクタリング後にすべてのテストを実行する必要があるため、Automation TestSuiteに追加されます。 したがって、TDDをサポートするテスト自動化ツールはこのプロセスを容易にします。 |
| TDDは、受け入れテストを開発者に渡すことを意味します。 | TDDは、開発者に受け入れテストを渡すことを意味するものではありません。 |
受け入れTDD
受け入れテスト駆動開発（ATDD）は、開発の初期段階で、ユーザーストーリーの作成中に受け入れ基準と受け入れテストを定義します。ATDDは、顧客、開発者、テスター間のコミュニケーションと共通理解に重点を置いています。
ATDDの主なプラクティスは次のとおりです-
ドメインの共通の理解を構築するために、実際のシナリオについて話し合います。
これらのシナリオを使用して、受け入れ基準に到達します。
受け入れテストを自動化します。
これらのテストに開発を集中させます。
変更を容易にするために、テストをライブ仕様として使用します。
ATDDを使用する利点は次のとおりです-
要件は明確で、機能的なギャップはありません。
開発者が予測する特殊なケースを理解している人もいます。
受け入れテストは開発をガイドします。
TDD対BDD
Dan Northによると、プログラマーは通常、テスト駆動開発の実行中に次の問題に直面します。
どこから始めれば
何をテストし、何をテストしないか
一度にいくらテストするか
彼らのテストを何と呼ぶか
テストが失敗する理由を理解する方法
これらすべての問題の解決策は、ビヘイビア駆動開発です。これは、確立されたアジャイルプラクティスから発展したものであり、アジャイルソフトウェア配信に不慣れなチームにとって、よりアクセスしやすく効果的なものにするように設計されています。時間の経過とともに、BDDは、アジャイル分析と自動受け入れテストの全体像を網羅するように成長しました。
メイン difference between TDD and BDD それは-
TDDは、ソフトウェアがどのように機能するかを記述します。
一方、BDD −
エンドユーザーがソフトウェアをどのように使用するかを説明します。
コラボレーションとコミュニケーションを促進します。
システムの動作の例に重点を置いています。
例から導き出された実行可能な仕様を目指します