BDD故事风格

Question

我们使用行为驱动发展开发了一个使用Scrum的面向服务的体系结构系统，并遇到了两种生成故事的方法。

Approach 1
    Given Specific Message Type is available
    And Specific State exists
    When the Message is processed
    Then expected resulting state exists

Approach 2
    Given a Specific state exists
    When Specific Message Type is processed
    Then expected resulting state exists

很少有可用的示例应用于SOA系统的测试。我希望对这些经验或对每一种方法的后果有任何见解。

我们的目标是陈述性故事而非祈使性故事。第一种方法中的消息到达有一种轻微的迫切性感觉，但我不相信第二种方法充分地涵盖了接受标准，因为它似乎没有考虑到SUT的事件驱动性质。

Answer 1

这个故事的目的是与你的客户沟通，所以无论哪种风格促进这个目标都是最好的--这将因团队而异。我可能更喜欢“当某些商业事件发生时”而不是你的建议，但我不知道你的团队！谨防试图找到一个“一刀切”的模板，使用任何沟通最好的每一种情况。敏捷的核心是适应能力--尝试一种风格，如果它似乎不起作用的话，可以自由地适应。

Answer 2

每当我生成库或服务时，我都会发现提供一个服务用户可能需要的场景示例是有用的。例如：

如果服务器有关于Lieumoney Brothers的风险限制的信息 我们从这些限制中得到了200万美元 当我们处理那些价值100万美元的爆炸物处理订单时 那么我们和Lieumoney兄弟的关系应该是Amber。

然后，电文的实际内容可以反映与这些特定金额和该特定对手方的互动。您可以将它用于许多不同的域，并且您的方法将取决于该域以及消息的可用性对于该域是否不寻常。在上面的例子中，你正在交易数百万美元，那么拥有特定对手的风险信息可能是有价值的，如果这是政府的话，那么这是值得单独指出的。例如，如果你买的是小兔子，那可能就不那么重要了。

鉴于“罗特维勒宠物有限公司”比其他任何人都便宜2美元 当我们要求系统订购15只小兔子时 然后向“罗特维勒宠物有限公司”下订单。

如果没有具体的例子，很难讨论这个问题。但是，您可能会看到提供这些场景将如何充当如何使用API的文档，即使这些场景的底层自动化直接与API对话，并且实际上没有任何特定于宠物或Lieumoney交易的文档。