我们使用Behaviour Driven Development使用SOA开发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系统，则很少。对于每种方法的后果，我都很感激这些或任何见解。
我们的目标是declarative rather than imperative stories。消息到达第一个有一点点迫不及待的感觉，但我不相信第二种方法能够充分涵盖验收标准，因为它似乎没有说明SUT的事件驱动性质。
答案 0 :(得分：3)
故事的目的是与您的客户进行沟通，因此无论风格如何促进这一目标是最好的 - 而且这种风格因团队而异。我可能更喜欢＆＃39;当一些商业活动发生时＆＃39;而不是你的建议，但我不了解你的团队！要小心试图找到一个适合所有人的＆＃39;模板，使用最适合每种情况的通信。敏捷的核心是适应能力 - 尝试一种风格，如果它似乎不起作用，可以随意适应。
答案 1 :(得分：1)
每当我创建一个库或服务时，我经常发现提供一个服务用户可能想要的场景的示例很有用。例如：
鉴于服务器有关于Lieumoney兄弟的风险限制的信息 我们距这些限制还要200万美元 当我们处理EOD订单时，我们将这些限额带到100万美元 那么我们与Lieumoney Brothers的地位应该是Amber。
然后，消息的实际内容可以反映与这些特定金额和特定交易对手的交互。您可以将此用于许多不同的域，并且您的方法将取决于域以及该域的消息可用性是否异常。在您上面交易数百万的上述示例中，为特定交易对手提供风险信息可能很有价值，如果是状态，则需要单独调用。例如，如果您购买小兔子，它可能就不那么重要了。
鉴于＆＃34; Rotweiller Pets Limited＆＃34;正在交换比其他任何人便宜2美元的小兔子 当我们要求系统订购15只小兔子时 然后它应该与＆＃34; Rotweiller Pets Limited＆＃34;订购。
如果没有具体的例子，很难讨论这个问题。但是，您可能会看到如何提供这些方案作为如何使用API的文档，即使这些方案的基础自动化直接与API进行对话，并且实际上没有特定于宠物或Lieumoney交易。