行为驱动开发是关于设计还是分析？
我对 BDD 以及如何改进 TDD 的了解越多，我就越感到困惑。我发现专家的引言说这是关于设计的，但也有其他专家说这是关于分析的。
我目前的看法是这样的：
1）分析：
来自 wikipedia 的
BDD面向对象分析的结果 是系统的描述 功能上需要做的，在 概念模型的形式。
因此，在 BDD 之后，我们就有了需求（故事和场景）。但我不确定概念模型部分。
2) 设计：例如使用 CRC 卡的责任驱动设计等工具
3) 代码：对设计进行编码，可选地使用测试（就像他们所说的 TDD 做错了，我也发现这很有用）
我的看法是错的吗？我现在很难透过树木看到森林。
The more I read about BDD and how it is supposed to be improved TDD the more confusing it all seems to me. I've found quotes from expert that say it's about design, but also from other experts that say it's about analysis.
The way I currently see it is this:
1) analysis: BDD
from 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.
So after BDD we have the requirements (stories and the scenarios). But I'm not sure about the conceptual model part.
2) design: eg with tools like resonsibility driven design using CRC cards
3) code: coding the design, optionally use testing (like what they say about TDD done wrong, which I also find useful)
Am I wrong in how I see this? I'm having trouble seeing the forest through the trees at the moment.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
简而言之，它与分析有关。
BDD 用于“验收测试驱动开发”——即了解被测系统是否按照特定用户故事场景的预期运行。
当我使用 Jbehave 时，我们在用户故事级别使用它，并且仍然使用“传统”TDD 来处理各个对象之间以及子系统之间的协作。
通常，业务系统使用 BDD 场景来描述业务域行为，而不是测试系统内部的微小实现细节。您希望 BDD 场景达到领域专家的抽象级别。这些场景对于领域专家来说没有多大意义，如果他们描述了实现的每个微小细节，这些场景将非常脆弱。
BDD 场景说明系统应该为用户故事执行什么操作，但不说明如何执行该操作。
In short it's to do with Analysis.
BDD is for "acceptance test driven development" - i.e. for knowing if a system under test behaves as expected for a specific user story scenario.
When I worked with Jbehave we used it at the user story level and still did "conventional" TDD for handling collaborations between individual objects and between subsystems.
Typically business systems use BDD scenarios to describe business domain behaviour not to test the tiny implementtion details inside the system. You want the BDD scenarios pitched at the domain expert's level of abstraction. Those scenarios wouldn't make much sense to domain experts and would be very fragile if they described every tiny detail of the implementation.
A BDD scenario says what the system should do for a user story but not how it does it.
BDD 是关于编写“可执行规范”或验收测试，又名黑盒测试，根据定义，采用测试对象的外部视角来派生测试用例。
所以BDD不能是关于设计的，BDD是关于测试功能/故事/场景的，BDD更接近于分析。
BDD is about writing "executable specifications" or acceptance testing a.k.a. black-box testing which, by definition, takes an external perspective of the test object to derive test cases.
So BDD can't be about design, BDD is about testing features/stories/scenarii, BDD is closer to analysis.
BDD - 行为驱动开发
行为 = ..在..的背景下
开发 - ...在构建...
在这种情况下，开发向我表明分析已经完成，并且正在实施特定行为背景下的某些内容。
所以为了回答这个问题，我相信它在设计中。
BDD - Behaviour Driven Development
Behavior = ..in the context of..
Development - ...in the construction of...
Development in this case indicates to me that the analysis has been done and one is implementing something that is in the context of a specific behaviour.
so to answer the question, I beleive its in the Design.
我认为从架构 POV 来看，BDD 与设计有关。我需要设计一个可以执行某些操作的应用程序，稍后将用于验收测试。因此，从高层设计的角度来看，我想确保我的设计是针对各种行为需求的，这样我就不会过度设计，并限制重复。
它有助于确保我们不需要重新设计，因为用户有更多的时间来思考他们真正想要看到的内容以及应用程序将如何执行。
I think from an architecture POV BDD would be about design. I need to design an application that can do something, that will later be used in acceptance testing. So, from the high-level design I want to make certain that I am designing for the various behavior requirements, so that I am not overdesigning, and limit duplication.
It helps with ensuring that we may not need to redesign as the user has has more time to think about what they actually want to see, how the application will perform.
BDD（或就此而言的 TDD）不关于任何事情。这是一种支持分析和设计（以及讨厌的小实现步骤）的技术（对于 BDD，更多的是一种方法）。您经常听到与 TDD 相关的短语“红、绿、重构”，因此它适用于 BDD：创建测试并查看它是否失败，通过更新代码库使测试通过，然后将系统重新设计为改进的形式，同时您保留通过的测试。
因此，BDD 在创建测试时支持分析：您应该以测试或示例的形式描述所需的行为。当您运行测试时，它支持设计：您的设计决策可以防止无意中破坏所需的行为，并且可以通过分析来指导。但它不会为您做任何分析或设计；你还得想一想。这是确保在分析和设计步骤中不会自相矛盾的一种方法。
BDD (or TDD for that matter) isn't about anything. It's a technique (in the case of BDD, more of an approach) that supports analysis and design (as well as that pesky little implementation step). You often hear the phrase "red, green, refactor" associated with TDD, and so it applies to BDD: create the test and see that it fails, make the test pass by updating the codebase, then rework the system into an improved form while you preserve the passing tests.
So BDD supports analysis when you create the tests: you should be describing the behaviour required in the form of tests or examples. It supports design when you run the tests: your design decisions are prevented from inadvertently breaking required behaviour, and can be guided by the analysis. But it doesn't do any of the analysis or design for you; you still have to think. It's a way of making sure that, during the analysis and design steps, you don't contradict yourself.
BDD 和 TDD 甚至有一个非常不吉利的名字，因为它实际上并没有涵盖它们的用途。
如果您在有一段代码描述您要编写的代码之前不编写一行代码，则 BDD/TDD 两者中的任何一个都可以。这样做你就会进入一个区域。
虽然没有证据表明 BDD/TDD 会提高您的开发速度（很可能不会），但它会大大减少您在发布已被证明的软件后遇到的问题数量。
BDD 是 TDD 的演变，其中 TDD 施加了测试所有内容的压力，BDD 放松了这一点，并表示您应该只测试类的公共行为，因为内部可能会发生变化。
BDD 与设计和分析一样重要，但我认为这不是您的问题，不是吗？您想知道如何将故事转化为流程图和架构图吗？
因为从我从你的问题中得到的信息是，你预先做了一个大的设计，然后尝试将其编码出来。这不适用于 BDD，因为在满足您应该以零碎方式编写的故事的同时，您会自动获得代码和架构。这被称为紧急设计，因此没有庞大的规划阶段。
在 SCRUM 或类似的系统中，这非常有效，因为业务会优先考虑您的故事。您从顶部开始并为其编写一个规范/示例，然后尝试重复此操作来满足示例，直到完成此积压项目，然后选择下一个并重新开始。
我希望这能回答您的问题。如果没有，您需要澄清一下，因为这是一个棘手的话题。简而言之，BDD 纯粹是一个开发人员工具，不适用于架构师、BA……测试人员可能会使用 BDD 工具，但我希望这不是他们用来测试应用程序的唯一工具。
BDD and TDD even more have a very unlucky name because it doesn't actually cover what they are used for.
BDD/TDD any of the 2 is fine if you don't write a line of code before you have a bit of code that describes the bit of code you're about to write. Doing that you'll get into a zone.
While there is no proof that BDD/TDD will improve your dev speed (most likely won't) it will greatly reduce the number of issues you get back after releasing the software which has been proven.
BDD is an evolution of TDD where TDD puts the pressure on to test everything BDD relaxes this and says that you should only test the public behavior of your classes because the internals are likely to change.
BDD is as much about design as it is about analysis, but I don't think that that is your question is it? You want to know how to translate the stories into flowcharts and architectural diagrams?
Because from what I get from your question is that you make a big design up front and then try to code that out. That won't work with BDD because whilst satisfying your stories which you should write in a piecemeal fashion your get your code and architecture automatically. It's called emergent design so there is no huge planning phase.
In a SCRUM or like wise system this works really well because the business prioritizes your stories. You start from the top and write a spec/example for it then try to satisfy the example repeating this until you've completed this backlog item and then pick up the next one and start over again.
I hope this answers your question.. if not you'll need to clarify a little because it's a braod topic. In short BDD is purely a developer tool, not for architects, BA's,... Testers may use the BDD tools but I hope that isn't the only tool they're using to test the application.