bdd - BDD 测试是验收测试吗？

Question

你需要像Fitnesse这样的东西吗？ , 如果您有 BDD测试？

Answer 1

BDD“测试”存在于多个不同的粒度级别，一直到最初的项目愿景。大多数人都知道这些场景。有几个人记得BDD started off with the word "should"作为 JUnit 的“测试”的替代品——作为 TDD 的替代品。我将“测试”放在引号中的原因是因为 BDD 并不是真正的测试；它专注于寻找缺乏理解或理解不匹配的地方。
由于这种关注，对话比 BDD 工具重要得多。
我要再说一遍。 对话比 BDD 工具重要得多。
验收测试实际上并不强制进行对话，并且通常假设您正在编写的测试是正确的测试。在 BDD 中，我们假设我们不知道我们在做什么(并且可能不知道我们不知道)。这就是为什么我们使用“Given、When、Then”之类的东西——这样我们就可以围绕场景和/或单元级示例进行对话。 (这是大多数人熟悉的两个级别 - 相当于验收测试和单元测试 - 但它会增加规模)。
我们不称它们为“验收测试”，因为您不能问业务人员“请帮助我进行验收测试”。他们会用一种非常奇怪的斜眼看着你，然后将你视为那个极客女孩。 93% 的人不希望那样。
试试“我想和你谈谈……的场景”。或者，“你能给我举个例子吗？”这两个都不错。称它们为“验收测试”会开始让人们认为您实际上是在进行测试，这意味着您知道自己在做什么并且只想确保自己已经完成了。在这一点上，谈话倾向于关注你能多快地解决错误的问题，而不是你解决错误的事实。
你弄错了。 Really, honestly, you are.即使你认为你不是，也只是因为你不了解二阶无知。你不知道你不知道，没关系，只要你找到了那些你可以知道你不知道的地方。 (你不会找到所有的。不要让分类悖论让你彻夜难眠。)
真正做到正确的唯一方法是预先获得所有要求，并且当您尝试这样做时您就会知道会发生什么。这是正确的。是瀑布。还记得加类吗？周末上类？在这七年中，您创造的东西没有一件投入生产？如果你想避免这种情况，你只有一次机会:假设你错了，就这件事进行一些对话以减少错误，然后接受你仍然错了，无论如何都要坚持下去。过早编写测试意味着你有更多的机会犯错，现在更难改变，每个人都认为你是对的，PM 正在衡量你的速度，现在你又犯了 2 周的错误。而且 - 更糟糕的是 - 你也将测试你错了。
再来一次。 对话比 BDD 工具重要得多。
拜托，拜托，不要专注于工具。这些工具只是一种捕获对话并确保它们在代码中发挥作用的机制。场景不能替代对话，任何超过 3 x 5 索引卡都可以替代需求。
话虽如此，如果你必须从一个工具开始，把 Slim 放在 Fitnesse 后面，这样它就可以运行可爱的 Given/When/Thens，而不必弄乱 Fit 的 table 和固定装置。 GivWenZen基于 Slim 和它们中的任何一个岩石。 FitSharp 相当于 .NET 领域的那些人。或者只使用 Cucumber、SpecFlow 或 knock up a little custom DSL*这将在几年内完成这项工作。
透明度:*我写了那个。还有一些 JBehave。我希望我们称它为“不要专注于 BDD 工具的行为”。我可能会大量参与 BDD 的其他部分。另外，如果我能把这条消息传出去，Dan North 会给我买一品脱，所以这不是完全公正的建议。
无论如何 - 已经进行了对话。这只是人。去谈。