我读到的关于BDD的内容越多,以及它应该如何改进TDD,这对我来说就更加混乱了.我发现专家的引言说它是关于设计的,但也有其他专家说这是关于分析的. 我目前看到它的方式是这样的：
我目前看到它的方式是这样的：
1)分析：BDD
从wikipedia
The result of object-oriented analysis
is a description of what the system is
functionally required to do, in the
form of a conceptual model.
所以在BDD之后我们有了要求(故事和场景).但我不确定概念模型部分.
2)设计：例如使用CRC卡的可靠性驱动设计等工具
3)代码：编码设计,可选择使用测试(就像他们所说的TDD做错了,我也觉得有用)
我怎么看错了？我现在很难看到森林穿过树林.
简而言之,这与分析有关.BDD用于“验收测试驱动开发” – 即用于了解被测系统是否表现为特定用户故事场景的预期.
当我与Jbehave合作时,我们在用户故事层面使用它,并且仍然使用“常规”TDD来处理单个对象之间和子系统之间的协作.
通常,业务系统使用BDD方案来描述业务域行为,而不是测试系统内的微小实现细节.您希望BDD场景适用于域专家的抽象级别.这些场景对领域专家来说没有多大意义,如果他们描述了实施的每一个细节,那将非常脆弱.
BDD场景说明了系统应该为用户故事做些什么,而不是如何做到这一点.