BDD和微型服务

Question

我们的解决方案依赖于微观服务。另一方面，我们的CIO期望我们在每一个新特性上实践行为驱动的开发。

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

编辑

更准确地说，在我看来，BDD测试需要验证业务逻辑，而且只验证业务逻辑。在许多框架中，BDD测试场景是由滑板持有者使用DSL创建的。BDD测试倾向于收敛到独占的“基础设施无知”实践。另一方面，集成测试应该验证解决方案是否匹配目标基础结构(它们是由DevOps ?)完成的，并且只有基础结构。当业务功能在微服务上“分布”时，您应该模拟BDD测试环境中的几乎所有东西(下面和业务)(应该是本地环境)，而模拟业务会大大削弱您的目标。你认为这些做法是相容的吗？

Answer 1

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

BDD只是指通过期望的行为来驱动您的设计，通常通过一组验收测试来表示。

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

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

因此，我将重点关注新特性所期望的行为，并首先为这些验收测试编写规范，然后实现您的服务，以满足所需的行为--根据需要以务实的方式添加较低级别的测试，同时要记住，测试越低，它们就越脆弱，并且需要在更改实现时进行更改。

编辑

根据你的问题编辑。

我不同意BDD测试应该只测试业务逻辑。事实上，通常情况下，BDD测试更侧重于测试整个系统，并将所有部分集成在一起。话虽如此，BDD只是通过指定所需的行为来进行测试的一种样式，并且可以应用于应用程序的任何级别。您可以通过使用Gherkin语法指定行为来测试单个类，我们有时会这样做。我们还指定了使用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'

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

Answer 2

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