1

我们使用行为驱动开发来使用Scrum开发SOA系统，并且遇到了两种生成故事的方法。

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 的事件驱动性质。

4

2 回答 2

3

故事的目的是与您的客户进行交流，因此无论哪种风格都能促进该目标，这将因团队而异。我可能更喜欢“发生某些业务事件时”而不是您的建议，但我不了解您的团队！谨防试图找到“一刀切”的模板，使用最适合每种情况的沟通方式。敏捷的核心是适应能力——尝试一种风格，如果它似乎不起作用，请随意适应。

于 2014-03-13T15:00:46.453 回答
1

每当我创建一个库或服务时，我经常发现提供一个服务用户可能想要的场景示例很有用。例如：

鉴于服务器有关于 Lieumoney Brothers 风险限制的信息
，我们从这些限制中获得 200 万美元
当我们处理 EOD 订单时，这些限制使我们达到 100 万美元，
那么我们在 Lieumoney Brothers 的状态应该是 Amber。

然后，消息的实际内容可以反映与那些特定金额和特定交易对手的交互。您可以将其用于许多不同的域，并且您的方法将取决于域以及该域的消息可用性是否异常。在上面的示例中，您交易数百万美元，那么拥有特定交易对手的风险信息可能很有价值，如果这是这种状态，则值得单独调用。例如，如果您要购买小兔子，这可能就不那么重要了。

鉴于“Rotweiller Pets Limited”的小兔子交易价格比其他任何人都便宜 2 美元
当我们要求系统订购 15 只小兔子
时，它应该向“Rotweiller Pets Limited”下订单。

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

于 2014-03-25T00:15:08.733 回答