为长篇故事编写 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.

有一些例子，如:

• Given > And(s) > When > And(s) > Then > And(s)
• Given > 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:

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

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

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 的 3 个方面:探索、规范和示例测试.大多数人关注其中的第二个和第三个，但第一个是隐含的.探索很重要，围绕场景进行对话是一种非常便宜的方式！

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^n 努力；算了吧.选择几个旅程(每个理想会话 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.

声明式优于命令式仍然是规则.避免谈论 UI；用每个阶段所取得的成就来描述旅程.

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!).

要具体.它不仅仅是用户"；是苏，路上的那个女孩，她在地图上使用你的多边形来试图发现她还没有抓到的口袋妖怪.具体的故事真的能激发人们的想象力，让旅程令人难忘.如果可以，让不同的旅程匹配不同的角色.

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.

如果您的常见客户旅程包括用户感到困惑、做错事或以其他方式浪费时间，请更改您的用户界面.用户体验专业知识仍然非常非常重要，并不是 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).当结果是旅程的重要组成部分时，然后"就会出现在旅程中，特别是提供用户必须具体响应的非特定指导.

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屋！