BDD测试是验收测试吗? [英] Are BDD tests acceptance tests?
问题描述
如果您具有BDD测试，是否需要类似Fitnesse的东西?
BDD测试"以多种不同的粒度级别存在，一直到最初的项目愿景.大多数人都知道这种情况.少数人记得 BDD开头是应该"一词，是JUnit的测试"-替代TDD.我在引号中加上测试"的原因是因为BDD并不是真正的测试.它的重点是寻找缺乏了解或不了解的地方.
由于专注，所以对话比BDD工具重要得多.
我再说一遍. 对话比BDD工具重要得多.
接受测试实际上并不强制对话，通常是在您编写的测试是正确的测试的前提下进行的.在BDD中，我们假设我们不知道自己在做什么(并且可能不知道我们不知道).这就是为什么我们使用给出，何时，然后"之类的原因的原因，以便我们可以围绕场景和/或单元级别的示例进行对话. (这是大多数人所熟悉的两个级别-等同于验收测试和单元测试-但规模越来越大.)
我们不称它们为验收测试"，因为您不能问业务人员请帮助我进行验收测试".他们会以一种怪异的，古怪的目光注视着你，然后把你当作那个怪胎女孩. 93％的人不想那样.
请尝试我想和您谈谈...的情况".或者，你能给我一个例子吗?"这些都不错.称它们为验收测试"开始使人们认为您实际上是在进行测试，这意味着您知道自己在做什么，而只是想确保自己已经完成了.那时，对话往往集中于您能以多快的速度找出错误的事情，而不是关注您正在发现错误的事情.
您发现错误的内容. 真的，老实说，你就是.即使你认为你是不是，这仅仅是因为您不了解二阶的无知.您不知道自己不知道，没关系，只要您找到了可以知道不知道的地方. (您不会找到所有的人.不要让分类悖论使您彻夜难眠.)
真正做到这一点的唯一方法是预先满足所有需求，并且您知道尝试执行该操作会发生什么.这是正确的.这是瀑布.还记得加班吗?周末工作?在您创造的一件事情中，有七年没有使它投入生产了吗?如果您想避免这种情况，您只有一次机会:假设您错了，就此事进行一些对话，以减少错误，然后接受您 still 仍然犯错，然后继续努力.过早地编写测试意味着您甚至有[em>更多次错误的机会，现在更难改变了，每个人都认为您是对的，并且PM正在衡量您的速度，现在您承诺要犯错再过两个星期.而且-更糟-您也要测试自己是否错了.
再一次. 对话比BDD工具重要得多.
请，请不要固定工具.这些工具只是一种机制，用于捕获对话并确保将其纳入代码中.方案不是对话的替代品，只是3 x 5索引卡替代了需求.
话虽如此，如果您必须开始使用工具，请将Slim放在Fitnesse后面，以便它可以轻松运行Given/When/Thens，而不必弄乱Fit的桌子和固定装置. GivWenZen 是基于Slim的，它们中的任何一个都是岩石. FitSharp在.NET空间中与您同等.或仅使用Cucumber或SpecFlow或稍微介绍一下自定义DSL * ，可以很好地工作多年.
透明度:*我写的是那个.还有一些JBehave.我希望我们称其为不要在BDD工具上集中行为".我可能会大量参与BDD的其他工作.另外，如果我能传达此信息，丹·诺特(Dan North)会给我买一品脱，所以这不是公正的建议.
无论如何-已经进行了对话.就是人聊吧.
Do you need something like Fitnesse, if you have BDD tests?
BDD "tests" exist at multiple different levels of granularity, all the way up to the initial project vision. Most people know about the scenarios. A few people remember that BDD started off with the word "should" as a replacement for JUnit's "test" - as a replacement for TDD. The reason I put "tests" in quotes is because BDD isn't really about testing; it's focused on finding the places where there's a lack or mismatch of understanding.
Because of that focus, the conversations are much more important than the BDD tools.
I'm going to say that again. The conversations are much more important than the BDD tools.
Acceptance testing doesn't actually mandate the conversations, and usually works from the assumption that the tests you're writing are the right tests. In BDD we assume that we don't know what we're doing (and probably don't know that we don't know). This is why we use things like "Given, When, Then" - so that we can have conversations around the scenarios and / or unit-level examples. (Those are the two levels most people are familiar with - the equivalent of acceptance tests and unit tests - but it goes up the scale).
We don't call them "acceptance tests" because you can't ask a business person "Please help me with my acceptance test". They'll look at you with a really weird, squinty gaze and then dismiss you as that geek girl. 93% of you don't want that.
Try "I'd like to talk to you about the scenario where..." instead. Or, "Can you give me an example?" Either of these are good. Calling them "Acceptance tests" starts making people think that you're actually doing testing, which would imply that you know what you're doing and just want to make sure you've done it. At that point, conversations tend to focus on how quickly you can get the wrong thing out, instead of about the fact you're getting out the wrong thing.
And you're getting the wrong thing out. Really, honestly, you are. Even if you think you're not, it's only because you don't understand second-order ignorance. You don't know that you don't know, and that's OK, as long as you've found the places where you could know you don't know. (You won't find all of them. Don't let the categorisation paradox keep you up at night.)
The only way to really get it right is to get all the requirements up front, and you know what happens when you try that. That's right. It's Waterfall. Remember the overtime? The weekend work? The seven years in which not one thing you created made it to production? If you want to avoid that, you only have one chance: assume you're wrong, have some conversations about it to be less wrong, then accept that you're still wrong and go for it anyway. Writing tests too early means you have even more chance to be wrong, and now it's harder to change and everyone thinks you're right and the PM is measuring your velocity and now you're committed to being wrong for another 2 weeks. And - worse - you're about to test that you're wrong, too.
Once again. The conversations are much more important than the BDD tools.
Please, please, don't fixate on the tools. The tools are just a mechanism for capturing the conversations and making sure that they get played into the code. Scenarios are not a replacement for conversations, any more than a 3 x 5 index card is a replacement for requirements.
Having said that, if you must start with a tool, put Slim behind Fitnesse so that it can run lovely Given / When / Thens without having to mess with Fit's tables and fixtures. GivWenZen is based on Slim and either of them rocks. FitSharp is the equivalent for those of you in the .NET space. Or just use Cucumber, or SpecFlow, or knock up a little custom DSL* that will do the job fine for years.
Transparency: *I wrote that one. And bits of JBehave. I wish we had called it "Dont-concentrate-on-BDD-tools-Behave". I might be heavily involved in other bits of BDD. Plus Dan North will buy me a pint if I can get this message out, so it's not exactly impartial advice.
Regardless - have the conversations already. It's just people. Go talk.
这篇关于BDD测试是验收测试吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
