当前位置: 首页 > 知识库问答 >
问题:

BDD和微服务

贡烨烁
2023-03-14

更准确地说,在我看来,BDD测试应该验证业务逻辑,而且只验证业务逻辑。在许多框架中,BDD测试场景是由滑板持有者用DSL创建的。BDD测试倾向于收敛于排他性的“不了解基础设施”的实践。另一方面,集成测试应该验证解决方案是否与目标基础结构匹配(它们由DevOps完成?),并且只与基础结构匹配。当业务功能通过微服务“分布”时,您应该模拟BDD测试环境(应该是本地环境)中的几乎所有内容(infra和business),而模拟业务会大大削弱您的目标。你认为这些做法是否兼容?

共有1个答案

经兴安
2023-03-14

为什么您认为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'
 类似资料:
  • 我读过一些关于如何用cuuumber实现BDD的文章,但我不能完全理解。 假设我有个服务 对于这3个输入,我正在寻找作为“1.jpg”的输出。 null

  • 我想知道每种方法的利弊是什么。例如,在graphQL中包含所有内容似乎有点多余,因为我们将在每个服务中复制模式的部分。另一方面,我们使用GraphQL来避免一些REST缺陷。我们担心拥有RESTendpoint会抵消从GQL获得的优势。 有人遇到过类似的困境吗?我们都没有使用GraphQL的经验,所以这里是否有一些明显的利弊我们可能会遗漏? 提前道谢!

  • 问题内容: 我们有几个微服务项目,每个项目都是独立的(在单独的spring boot服务器上运行,公开其余服务,使用单独的DB模式…) 我们使用Maven管理依赖关系。 有一个父pom将每个微服务声明为模块是一个好主意吗?因此,有助于管理公共依赖项(例如,在每个项目中都使用lib servlet-api witch,将其全部删除并仅在父pom中声明) 问题答案: 多模块父pom的“问题”是,没有复

  • 我们有几个项目是微服务,每个项目都是独立的(在单独的spring boot服务器上运行,公开rest服务,使用单独的DB模式…) 我们使用maven来管理依赖关系 让父pom将每个微服务声明为模块是个好主意吗?因此有助于管理公共依赖项(就像每个项目中使用的lib servlet-api女巫一样,将其全部删除并仅在父pom中声明它)

  • 微服务作为一种软件架构风格正在获得牵引力,它将更好地支持持续交付,为快速部署和关注点分离提供模型。 Vert.x 3和Vert.x-Apex为构建微服务提供了一个有趣的模型。如其中一个例子所示,一个简单的verticle可以公开一个HTTP服务,因此REST服务是可用的。垂直绑定它自己的tcp端口。 当扩展到多个微服务来支持一个完整的应用程序时,您最终会有许多选择。对于哪种风格能够最终支持连续交付

  • 让我们讨论一下微服务环境的体系结构。我们正在公司内部进行讨论,我想得到一些反馈。我认真考虑的是编排层(代码复制、更多移动部件改变api)。 网络应用- 原料药- 在这种情况下,服务不允许相互对话。业务流程层中的聚合服务 网络应用- 原料药- 这里允许服务相互对话,这里存在聚合服务。 账单属于哪里