C# BDD和微服务

我们的解决方案依赖于微服务。另一方面，我们的首席信息官希望我们在每一项新功能上实践行为驱动开发

是否可以在微服务体系结构中管理BDD？根据您的经验，针对这种体系结构采用BDD是一种好的做法，还是您认为我们应该直接考虑集成测试

[编辑]

---

更准确地说，在我看来，BDD测试应该验证业务逻辑，并且只验证业务逻辑。在许多框架中，BDD测试场景是由Skateholder使用DSL创建的。BDD测试趋向于收敛于排他性的“基础架构无知”实践。另一方面，集成测试应该验证解决方案是否与目标基础架构匹配（它们是由DevOps完成的？），并且只与基础架构匹配。当业务功能在微服务上“分布”时，您应该模拟BDD测试环境（应该是本地环境）中的几乎所有内容（infra和business），模拟业务会大大削弱您的目标。您认为这些实践是兼容的吗？

为什么您认为BDD和集成测试是不同的

BDD仅仅意味着通过期望的行为来驱动您的设计，通常通过一组验收测试来表达

这些测试可能是涉及许多[微]服务的“集成测试”，也可能是指定单个服务或该服务中单个类的期望行为的测试。理想情况下，将在所有这些级别进行混合测试。重要的是，您需要指定您想要的行为，并使用它来驱动开发

在某种程度上，系统的实现方式是无关紧要的，只要它表现出预期的行为。对于将系统视为黑匣子的高级测试，这是正确的，并且越低，越接近实际代码，这就越不正确（因为此时您正在有效地测试实现）

因此，我将重点关注新功能的预期行为，并首先为这些验收测试编写规范，然后实施您的服务以满足所需的行为，并根据需要以务实的方式添加较低级别的测试，请记住，测试级别越低，越有可能变得脆弱，并且在更改实现时需要更改

编辑

根据您的问题进行编辑

我不同意BDD测试应该只测试业务逻辑。事实上，BDD测试通常更侧重于测试整个系统，将所有部分集成在一起。话虽如此，BDD只是一种通过指定所需行为的测试样式，可以应用于应用程序的任何级别。您可以通过使用Gherkin语法指定行为来测试单个类，我们有时会这样做。我们还指定了使用小黄瓜的整个系统的预期行为以及我们服务的预期行为。根据我们的目标水平，这些测试的形式自然会略有不同

对于系统测试，我们可能有如下规范：

Scenario: user can perform action A
   Given I am a user with access to some feature A
   And feature A is enabled for the user
   When I call perform action A with parameters 'Bob' and 'John'
   Then A 'BobJohn' is created
   And notifications are sent to the current user

对于单个服务，我们可能会进行如下测试

Scenario: create messages are handled correctly
   Given the service is set up
   When a message arrives to create a 'BobJohn'
   Then a new entry is added to the database with the key 'BobJohn'
   And an outgoing notification message for 'BobJohn' is created

Scenario: Notifier class should send notifications via all users preferred means
    Given the current user wants notification by Twitter
    And the current user who wants notification by email
    When I send the notification 'BobJohn' to the current user
    Then the twitter notifier should be invoked with 'BobJohn'
    And the email notifier should be invoked with 'BobJohn'

对于单个类，我们可能有如下测试

Scenario: create messages are handled correctly
   Given the service is set up
   When a message arrives to create a 'BobJohn'
   Then a new entry is added to the database with the key 'BobJohn'
   And an outgoing notification message for 'BobJohn' is created

Scenario: Notifier class should send notifications via all users preferred means
    Given the current user wants notification by Twitter
    And the current user who wants notification by email
    When I send the notification 'BobJohn' to the current user
    Then the twitter notifier should be invoked with 'BobJohn'
    And the email notifier should be invoked with 'BobJohn'

---

这些都是BDD风格的测试，但它们测试系统的不同方面

我相信对服务进行功能测试的能力是质量的良好标志。集成测试是昂贵、缓慢和痛苦的。集成测试不是说明您的行为是否正确的地方，它的历史目的是说明组件是否正确交互。

非常感谢您的反馈，我部分同意您的意见，但这正是我问题的全部目的。我编辑了这个问题，你觉得怎么样？谢谢你的反馈Sam《行动中的BDD》的作者认为它们是兼容的：谢谢你注意到了这一点。我刚刚读了JFSmart写的一些文章，我们在这个问题上有相同的观点。他说，它们在发展的不同阶段是兼容的。如果解决方案体系结构使其成为可能（我希望下降体系结构使其成为可能），那么BDD最适合于业务验收测试。验收测试确定后，集成测试旨在针对目标基础架构测试解决方案。关注点分离。他声称，从集成测试中将默认验收推给开发人员是浪费时间。兼容，但不一样。