12

重複の可能性:
ユニットテスト用のSpecFlow / BDD?

過去数年間、私はNUnit / Moqを使用してTDDで作業し、過去数か月間、mSpecを使用してBDDを理解するようになりました。

これまでのところ良好ですが、ビジネスアナリストが関与し、開発プロセスの外部にいる受け入れ基準ベースのテストにさらに移行したいと考えています。

これで、Gherkin構文ファイルが事前定義されました。specflowを使用すると、正しい動作方法を感じることができます。

ただし、ユニットテストレベルでは、事前定義されたGherkinファイルがあると、TDDについて私が理解していることに反します。言い換えれば、あなたは行動とともにあなたのデザインを長く進化させながらデザインします。

外部アプローチを使用して作業しているため、ユニットテストレベルでは、ユニットテストを実行するために使用できる仕様/動作が得られた可能性があります(TDDの実行方法に反しているように感じます) )?

以前のこれらのファイルは受け入れテストにとって重要でしたが、開発者として私は一人で作業するので、SpecFlowを使用しない限りこれらのファイルは必要ありません。

また、mspecを使用しているときにGWTファイルを維持する単体テストレベルでどのようなメリットがありますか?開発者は、コードに飛び込んでテストを読むか、テストランナーを実行して何が行われているかを確認できる必要があります。

TIA JD

4

1 に答える 1

15

私の自発的な答えはノーです。

BDD と、specflow や Cucumber などのツールの主な利点は、プロジェクトの利害関係者とのコミュニケーションと、何を構築するかについての共通の理解を作成することです。

TDD の主な利点は、ソリューションの実装を通じて小さなステップを踏むことで、保守可能で優れたコードを確実に構築できることです。

または、必要に応じて; BDD は正しいものを構築していることを保証するものであり、TDD は正しく構築していることを保証するものです。

詳細が必要な場合は、先日私のブログでこのような質問に答えました。http://www.marcusoft.net/2011/11/bdd-and-technical-scenarios.html

于 2011-11-24T12:56:18.077 に答える