撰写长篇故事的BDD的最佳方法 [英] Best ways to write BDD for long stories

问题描述

我们最近开始使用BDD来编写我们的需求.这确实很有帮助，它使分析人员和开发人员之间的交流变得更加容易. (结合用户界面和旧学校要求)

We have recently started using BDD to write our requirements. It's been really helpful, it made the communication between analysts and developers a lot easier. (Combined with user interfaces, and old school requirements)

现在，我们正在考虑使用BDD编写测试用例.当我在线搜索最佳实践时，我发现如何编写它们会有很多不同的变化.

Now we are thinking about writing our test cases with BDD. When I search online for the best practices I see a lot of different variations on how to write it.

有一些示例，例如:

• 给出> And(s)> When> And(s)>然后> And(s)
• 给出> And(s)> When> Then> And(s)

问题几乎是所有示例都是针对非常简单的情况，另一方面，我们想编写包含多个动作，多个系统输出(警告，错误等)和多个输出的场景.

Problem is almost all examples are for very simple cases, on the other hand we'd like to write scenarios that includes multiple actions, multiple system outputs (warnings, errors etc.) and multiple outputs.

我们正在尝试为以下情况找到编写BDD的最佳方法:

We are trying to figure out best way to write BDD for following scenario:

• 我们需要检查用户是否被授权
• 他/她在正确的模块中

我们希望用户执行以下操作:

We want user to do following actions:

• 用户设置开始日期
• 用户设置结束日期
• 用户选择类别
• 用户选择子类别(基于所选类别)
• 用户点击运行
• 由于地图上没有多边形，系统会发出警告
• 用户关闭警告
• 用户在地图上绘制多边形(绘制多边形的每个步骤都在后端进行验证，并在地图上直观地呈现)
• 用户停止绘图
• 用户点击运行
• 系统生成图表.

• User sets a start date
• User sets an end date
• User selects a category
• User selects sub-categories (based on selected category)
• User clicks Run
• System throws a warning because there is no polygon on map
• User close the warning
• User draws a polygon on map (and each step to draw a polygon has a validation in backend, and visually rendered on map)
• User stops drawing
• User clicks Run
• System generates a chart.

之所以这么长，是因为这是可能发生的常见情况，我们希望确保用户能够回到快乐的道路上.

The reason we have such a long story is that this is a common scenario that can happen and we want to make sure that users are able to go back to happy path.

您认为使用BDD处理这种情况的最佳方法是什么?

What do you think is the best way to handle such scenario using BDD?

推荐答案

我将尝试在此处重新表述您的要求，以期能够解决一些问题.

I'm going to try and rephrase what you're asking for here, in the hopes that it will clear some things up.

我们最近开始使用BDD来编写我们的需求...现在我们正在考虑使用BDD编写我们的测试用例.

We have recently started using BDD to write our requirements... Now we are thinking about writing our test cases with BDD.

我们最近开始使用示例来阐明我们的要求...现在我们正在考虑使这些示例自动化.

We've recently started to use examples to clarify our requirements... now we're thinking of automating those examples.

当我在网上搜索最佳做法时，我会看到很多不同的写法.

When I search online for the best practices I see a lot of different variations on how to write it.

当我在线搜索时，我会看到许多不同的背景，事件和结果变体.

When I search online, I see a lot of different variations of context, event and outcome.

(这不只是在写作中；而是在导致写作的对话中.这就是为什么会产生差异的原因；因为对话确实很模糊.)

(It's not just in the writing; it's in the conversation that leads to the writing. This is why you get variation; because conversation is really fuzzy.)

问题是几乎所有示例都是针对非常简单的情况

Problem is almost all examples are for very simple cases

问题在于，在过去，像我这样的早期采用者以登录为例.

The problem is that back in the old days, early adopters like me used things like login as an example.

我们这样做是错误的.简单的示例实际上并不能帮助您理解BDD.整个优点是，当我们与了解问题的利益相关者(例如，他们可能是安全或基础结构专家；不仅仅适用于业务专家)进行交谈时，我们学习了.这是关于我们所做的事情的谈话在BDD的早期错了；您会遇到其中一些成本.抱歉.

We were wrong to do so. Simple examples don't actually help you understand BDD. The whole beauty was that when we talked to the stakeholders who understood the problem (who might be security or infrastructure experts, for example; it doesn't just apply to the business experts), we learned something. Here's a talk on the things that we did wrong back in the early days of BDD; you're encountering the cost of some of those. Sorry.

我写了整个博客文章 BDD的三个方面:示例探索，规范和测试.大多数人专注于其中的第二和第三，但是第一是隐含的.探索很重要，围绕场景进行对话是一种非常便宜的方法！

I wrote a whole blog post on the 3 aspects of BDD: Exploration, Specification and Test by example. Most people focus on the 2nd and 3rd of those, but the 1st is implicit. Exploring is important, and conversations around scenarios are a really cheap way to do that!

我们想编写包含多个动作，多个系统输出(警告，错误等)和多个输出的方案...我们之所以长话不说是因为这是可能发生的常见方案，并且我们希望确保用户能够回到快乐的道路.

We'd like to write scenarios that includes multiple actions, multiple system outputs (warnings, errors etc.) and multiple outputs... The reason we have such a long story is that this is a common scenario that can happen and we want to make sure that users are able to go back to happy path.

我们想检查整个客户旅程，以确保我们的系统至少可以使用，无论发生什么其他情况.

We want to check full customer journeys to make sure that our system is at least usable, no matter what else happens.

因此，如果您想使用Cucumber之类的BDD工具来编写完整的，全栈的，自动的客户旅程，而不是行为的一个方面(我们称为场景)的单个示例.不是BDD.

So, if you're wanting to use BDD tools like Cucumber to write a whole, full-stack, automated customer journey, rather than a single example of one aspect of behaviour (what we call a scenario), then... it's not BDD.

但是，它仍然是一个好主意.它不是BDD，但这并不意味着这是一件坏事.我曾与许多组织合作，并从中受益. (也许应该有一个名字.)

However, it is still a really good idea. It's not BDD, but it doesn't mean it's a bad thing. I've worked with a number of orgs who've done this and benefited from it. (Maybe it should have a name.)

以下是根据经验我可以给您的提示和技巧:

Here are the hints and tips I can give you based on that experience:

• 不要不将它们用作回归测试！尝试经历每一次旅程都需要花费2倍的努力.算了吧.选择一些旅程(每个理想的会话3次似乎很典型)，然后尝试选择不同但典型的客户选择.不要使用这些来测试边缘情况.您只是在检查您的主要客户旅程是否仍然缝合在一起.

• Do not use these as regression tests! Trying to go through every journey is an exponential 2^n effort; forget it. Pick a few journeys (3 per ideal session seems pretty typical) and try to pick different, but typical, customer choices. Don't use these to test the edge-cases. You're just checking that your main customer journeys are still stitched together.

基于命令式静止规则的声明式.避免谈论用户界面；根据每个阶段的成就来表述旅程.

Declarative over Imperative still rules. Avoid talking about the UI; phrase the journey in terms of what's being achieved at each stage.

如果可以执行此操作，则可以从较小的场景中重用您的步骤.将客户旅程(有时称为烟雾测试")放在单独的位置，即使它们在构建的同一部分中运行也是如此.首先运行它们，直到不再需要为止(一个月左右的中断将使团队修复根本原因，环境问题等！).

If you can do this, you get to reuse your steps from your smaller scenarios. Put your customer journeys (sometimes referred to as "smoke tests") in a separate place, even if they're run in the same part of the build. Run them all first, until you don't need to any more (a month or so of these breaking will make the team fix the root cause, environment issues, etc!).

要具体.不只是用户"；是Sue，这名路边的女孩正在她的地图上使用您的多边形来尝试发现尚未捕获的Pokemons.特定的故事真正抓住了人们的想像力，使旅途令人难忘.如果可以，请使不同的旅程与不同的角色匹配.

Be specific. It's not just "a user"; it's Sue, the girl down the road who's using your polygons on her map to try to spot Pokemons she hasn't caught yet. Specific stories really catch people's imagination and make the journeys memorable. Make different journeys match different personas, if you can.

通常情况下，一种情况的当时"形成了行为不同方面的另一种情况的给予".如果将它们串在一起，请不要担心那么".如果您要在下一步中使用它，则无需检查结果.例如，如果菜单需要显示特定的选项，则不要检查该选项；只是使用它并假设它在那里. UI检查可能会很昂贵，并且经过这些较长的旅程，我们应该将其放在通常可以通过的地方.如果不是，那么在我们弄清楚它们为什么被破坏的时期内添加缺失的步骤是很琐碎的.通常，这些集成测试比什么都重要.在运行较长的场景套件之前，请检查特定服务是否已连接等.

Often the "then" of one scenario forms the "given" of another one with a different aspect of behaviour. If you're stringing them together, don't worry about the "then". You don't need to check for the outcome if you're about to use it in the next step. For instance, if a menu needs to show a particular choice, don't check for the choice; just use it and assume it's there. UI checks can be expensive and with these longer journeys we should be in a place where these are generally passing. If they're not, it's pretty trivial to add the missing steps for the period in which we're working out why they're broken. Usually these are integration tests more than anything; checking that particular services are connected, etc., before the longer scenario suite is run.

如果您的常见客户旅程包括用户感到困惑，做错事或浪费时间，请更改您的UI.用户体验方面的专业知识仍然非常重要，并且并不是BDD的真正组成部分，因为与UI的比较和建议相比，很难为简单"或宽容"提供具体的示例. BDD不是灵丹妙药.

If your common customer journey includes users being confused, doing the wrong thing or otherwise wasting their time, change your UI. User Experience expertise is still really, truly important, and isn't really part of BDD, since it's hard to come up with concrete examples for "easy" or "forgiving" compared to comparisons and suggestions for UI. BDD isn't a silver bullet.

记录下围绕整个客户旅程的对话中的工件，甚至散布在办公室的整个墙上是很常见的.但是，自动版本通常是在较小的场景已经完成并且功能正常运行后 创建的.

It's very common to have the artifacts from the conversations around full customer journeys written down or even spread across an entire wall of an office. The automated versions, however, are normally created after the smaller scenarios have been completed and the functionality is working.

通常，在完整的，端到端的客户旅程与覆盖行为(如边缘案例)的较小方案之间存在重复.端到端的旅程提供了快速的反馈，并确保没有人在浪费时间；较小的方案提供了有关系统应如何运行的文档.在这种情况下可以进行复制.

There is normally duplication between the full, end-to-end customer journeys and the smaller scenarios that cover aspects of behaviour like edge-cases. The end-to-end journeys provide fast feedback and ensure that nobody's time is being wasted; the smaller scenarios provide documentation on how the system should behave. Duplication in this instance is OK.

如果您决定希望这是一个完整的旅程，那么这就是我希望看到的事情(而我在这里所做的只是声明式与命令式"的事情):

If you decide that you want this to be a full journey, here's the kind of thing I'd expect to see (and all I'm doing here is the "declarative vs. imperative" thing):

Given Sue's registered to catch Pokemons  
And Bulbasaurs, Koffings and Pikachus were caught in Trafalgar square this year
When she filters for Pokemons caught between January and July
And adds a filter for "Poison" traits
And filters for "Bulbasaur"
When she searches for Pokemons
Then she should be asked to select an area of the map
When she selects an area around Trafalgar Square
Then she should be shown the Bulbasaur density
But not the Pikachu or Koffing density.

使用具体示例.当上面有一些实际想法时，更容易理解和发现上面的缺陷，或者对我对Pokemon Go的理解(我还没有玩过)更容易.在这些旅程和较小的场景之间是有共同点的.

Use specific examples. It's much easier to understand and see flaws in the above, or on my understanding of Pokemon Go (which I haven't yet played) when it actually has realish ideas in it. That's something in common between these journeys and smaller scenarios.

您还将看到有很多很多的时间"，它们都相互融合.如果我们只讨论行为的各个方面，那么每个方面都将以给定"作为开头，概述以前发生的情况，而允许下一个何时"成为的结果则是当时".在这种情况下，尽管我们将它们链接在一起.在这些类型的旅程中，时间"的不间断序列非常普遍并且完全可以，只要您认为这不是不是就行为的一个方面，也不提供它的示例(因此，并不是真正的BDD).当结局是旅程中的重要部分时，就会出现"Thens"旅程中途，特别是提供非特定的指导，用户必须对此做出具体反应.

You'll also see that there are many, many "whens", and they all feed into each other. If we were discussing single aspects of behaviour, each of these would be prefaced by a "given" outlining the context of what came before, and the outcome which allowed the next "when" would be the "then". In this case though we're chaining them together. Uninterrupted sequences of "whens" are very common and completely OK in these kinds of journeys, so long as you respect that this is not looking at a single aspect of behaviour, nor providing examples of it (so it's not really BDD). "Thens" mid-journey appear when the outcome is an important part of the journey, particularly providing non-specific guidance which the user has to respond to specifically.

不要在误解到位的情况下自动执行这些操作！自动化的客户旅程代表了一笔巨大的投资(尽管一旦涉及相同功能的较小方案很容易组合在一起).首先使功能起作用，然后将其展示给相关的利益相关者.您不想在可能因学习和反馈而改变的事情上投入大量资金.

Do not automate these with misunderstandings in place! Automated customer journeys represent a significant investment (though they're pretty easy to put together once you have smaller scenarios covering the same functionality). Get the functionality working first, and show it to the relevant stakeholders. You don't want to invest heavily in things that are likely to change with learning and feedback.

希望这会有所帮助，并感谢您让我认真考虑！

Hope this is helpful, and thanks for making me think this through!

这篇关于撰写长篇故事的BDD的最佳方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！