単体テストは、コード テストを記述する練習です。TDD は、それらを「前に」書く慣行です。BDD は、動作/仕様駆動型のテストを作成する方法です。BDD は「後」に記述できますか?それとも常に「前」に記述する必要がありますか?
BDD を「後」に書き、それが BDD ではない場合、それは何と呼ばれますか?
4 に答える
3
ビヘイビア駆動開発 (BDD) はテスト駆動開発 (TDD) のバリエーションであり、TDD と同様に最初にテストを作成する必要があります。
一部の人々は、TDD が正しく行われたこと、または意図された方法で BDD と呼んでいます。また、BDD はドメイン駆動開発 (DDD) と TDD の混合であると言えます。
于 2012-04-20T06:17:38.943 に答える
0
私は、BDD-Afterが単に検証を書く場合であるという観察が好きです。また、BDD-Afterを実行している開発者がBDD-As-You-Goの他の利点のいくつかを見逃しているというコメントにも感謝します。追加する価値があると思われる1つのポイントは、実装前にsecenario / testを作成し、テストに合格することも、テスト自体が健全であることの一種の検証であるということです。すでに機能している機能（BDD-After）の合格テストを作成すると、開発者は、機能が壊れた場合にテストが「適切に失敗する」かどうか疑問に思うかもしれません。
于 2012-09-22T16:55:59.030 に答える
0
開発後のBDDはBDDではなく、仕様ではなく検証の場合です。
ただし、他の人が述べたように、事後に受け入れテストスイートを追加しても価値がないという意味ではありません。さらなる開発 (大規模なリファクタリング ジョブまたは新機能の追加) に進む前に、動作を検証する一連の回帰受け入れテストを構築します。
経験上、このタスクを実行する場合、本番コードを作成した主要な開発者は、受け入れテスト (できれば Gherkin スクリプトの形式) を作成することから十分に離れていることが最善です。それらを書いている人は、元の要件ドキュメント (存在する場合) に戻り、その際に一部の利害関係者と協力することは間違いありません。これは、作成した受け入れテストが仕様に近いものであることを確認するのに役立ちます。
于 2012-05-25T15:31:23.300 に答える