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样式测试,但它们测试系统的不同方面.