敏捷雑談のTDDとBDD
敏捷開発には多くの方法があるが、いずれを採用しても、テストは敏捷な基礎を実施し、コードの正確性をタイムリーに検証し、システム機能の健全性、タイムリーなフィードバック、タイムリーな停止を保証する......は敏捷な基礎である.そのため、大量の迅速な自動化テストは、迅速な開発が迅速な反復の中でソフトウェアの品質をあまり失わないことを保証することができます.
そのため、敏捷な開発では「コードはドキュメント」という説があり、テストコードも機能コードの使用ドキュメントとなっている.敏捷に強調したTDD(Test-driven developmenet、テスト駆動開発)は、主にこのような思想を体現している:設計に基づいてテストを書く->設計を実現する機能を実現する->テストコードで検証する->実現コードを再構築する->設計を改善する->改善に基づいてテストを書く.繰り返し繰り返していくのが、TDDが提唱している流れです.
TDDのメリット:1.システムの最終的な実装コードを駆使することができ、テストコードによって上書きすることができ、すなわち「各行のコードは測定可能」である.2.テストコードはコードを実現する正確なガイドとして、最終的に正確なシステムの行為に発展し、開発過程全体をより効率的にすることができる.TDDの不足点あるいは不十分な点は,設計とテストの作成に明確な方針がないことである.サイクル全体のウィザード部分として、設計に基づいて作成されたテストがエンドユーザーが望むシステム動作であることをどのように保証しますか?この部分がぼやけていると、後続のすべての部分がほとんど影響を受けます.そのため、再びその上で、敏捷なコミュニティはまたBDDの概念を提出して、つまり“行為が開発を駆動します”.
BDD(Behavior-driven development)はTDDのあいまいな部分を明確にし、開発、テスト、BA、顧客などすべてのプロジェクト関係者が自然言語でシステムの行為を記述していることを強調した.皆さんがご覧の説明は一致しており、読んだ内容は一致しており、最終的なテスト駆動開発の結果もユーザーの期待に最も合っているはずです.そこでBDDの提唱の下で,Gherkin Languageという簡潔な自然言語を紹介した.システム挙動をGherkin Languageで記述した例を以下に示す.
BDDの出現と発展に伴い,皆が容易に理解し認知できる言語を用いてシステムの挙動を記述し,User Storyを作成することで,TDDの繰り返しループの流れもよりスムーズに進むことができるようになった.BDDの核心価値はシステムの行為を正確に設計することに現れているので、それは有効なテスト方法ではありません.これは、システムの最終的な実装がユーザの所望の動作と一致し、コード実装が設計目標に合致するかどうかを検証することを強調する.しかし、それ自体はシステムの機能、性能、境界値などの健全性を保証することを強調しておらず、完全なテストのようにシステムの様々な問題を発見することはできない.
BDDはTDDの進化という説があるが、筆者から見れば、どちらが優れているか、どちらが劣っているかは、本質と目標が一致している.ただ、実施方法については、敏捷な開発システム全体を改善するために異なる検討を行った.BDDに書かれたUser Storyやテストケースと呼ばれ、開発、テスト、顧客などが共に参加し、見ることができない一貫性のある内容であれば、その価値もほとんど現れない.もう1つは、完全なテストに代わるものではなく、システムの動作を記述することを目的としているため、Gherkin Languageの例が示すように、肝心なのは「簡潔さ」であり、一歩一歩一歩の操作や状況をはっきり言いたいとくどくど言うのは禁物である.
最後にまとめた:TDDの反復繰り返し検証は敏捷な開発の保障であるが、どのように設計に基づいてテストを生成し、テスト用例の品質を保障するかは明確ではない.BDDはみんなが簡潔な自然言語でシステム行為を記述する理念を提唱し、テスト用例(すなわちシステム行為)の正確性を適切に補った.(以上の理念が進んでいるかどうかにかかわらず、盲従や乱用は禁物)
そのため、敏捷な開発では「コードはドキュメント」という説があり、テストコードも機能コードの使用ドキュメントとなっている.敏捷に強調したTDD(Test-driven developmenet、テスト駆動開発)は、主にこのような思想を体現している:設計に基づいてテストを書く->設計を実現する機能を実現する->テストコードで検証する->実現コードを再構築する->設計を改善する->改善に基づいてテストを書く.繰り返し繰り返していくのが、TDDが提唱している流れです.
TDDのメリット:1.システムの最終的な実装コードを駆使することができ、テストコードによって上書きすることができ、すなわち「各行のコードは測定可能」である.2.テストコードはコードを実現する正確なガイドとして、最終的に正確なシステムの行為に発展し、開発過程全体をより効率的にすることができる.TDDの不足点あるいは不十分な点は,設計とテストの作成に明確な方針がないことである.サイクル全体のウィザード部分として、設計に基づいて作成されたテストがエンドユーザーが望むシステム動作であることをどのように保証しますか?この部分がぼやけていると、後続のすべての部分がほとんど影響を受けます.そのため、再びその上で、敏捷なコミュニティはまたBDDの概念を提出して、つまり“行為が開発を駆動します”.
BDD(Behavior-driven development)はTDDのあいまいな部分を明確にし、開発、テスト、BA、顧客などすべてのプロジェクト関係者が自然言語でシステムの行為を記述していることを強調した.皆さんがご覧の説明は一致しており、読んだ内容は一致しており、最終的なテスト駆動開発の結果もユーザーの期待に最も合っているはずです.そこでBDDの提唱の下で,Gherkin Languageという簡潔な自然言語を紹介した.システム挙動をGherkin Languageで記述した例を以下に示す.
As a xxx [Role]
I want to xxx [Feature]
So that I can xxx[Benefit]
Scenario 1: create user
Given a admin log into the system
when he create a user with name 'mike'
then mike should be able to log into the systemBDDの出現と発展に伴い,皆が容易に理解し認知できる言語を用いてシステムの挙動を記述し,User Storyを作成することで,TDDの繰り返しループの流れもよりスムーズに進むことができるようになった.BDDの核心価値はシステムの行為を正確に設計することに現れているので、それは有効なテスト方法ではありません.これは、システムの最終的な実装がユーザの所望の動作と一致し、コード実装が設計目標に合致するかどうかを検証することを強調する.しかし、それ自体はシステムの機能、性能、境界値などの健全性を保証することを強調しておらず、完全なテストのようにシステムの様々な問題を発見することはできない.
BDDはTDDの進化という説があるが、筆者から見れば、どちらが優れているか、どちらが劣っているかは、本質と目標が一致している.ただ、実施方法については、敏捷な開発システム全体を改善するために異なる検討を行った.BDDに書かれたUser Storyやテストケースと呼ばれ、開発、テスト、顧客などが共に参加し、見ることができない一貫性のある内容であれば、その価値もほとんど現れない.もう1つは、完全なテストに代わるものではなく、システムの動作を記述することを目的としているため、Gherkin Languageの例が示すように、肝心なのは「簡潔さ」であり、一歩一歩一歩の操作や状況をはっきり言いたいとくどくど言うのは禁物である.
最後にまとめた:TDDの反復繰り返し検証は敏捷な開発の保障であるが、どのように設計に基づいてテストを生成し、テスト用例の品質を保障するかは明確ではない.BDDはみんなが簡潔な自然言語でシステム行為を記述する理念を提唱し、テスト用例(すなわちシステム行為)の正確性を適切に補った.(以上の理念が進んでいるかどうかにかかわらず、盲従や乱用は禁物)