更准确地说,在我看来,BDD测试应该验证业务逻辑,而且只验证业务逻辑。在许多框架中,BDD测试场景是由滑板持有者用DSL创建的。BDD测试倾向于收敛于排他性的“不了解基础设施”的实践。另一方面,集成测试应该验证解决方案是否与目标基础结构匹配(它们由DevOps完成?),并且只与基础结构匹配。当业务功能通过微服务“分布”时,您应该模拟BDD测试环境(应该是本地环境)中的几乎所有内容(infra和business),而模拟业务会大大削弱您的目标。你认为这些做法是否兼容?
为什么您认为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)。 网络应用- 原料药- 在这种情况下,服务不允许相互对话。业务流程层中的聚合服务 网络应用- 原料药- 这里允许服务相互对话,这里存在聚合服务。 账单属于哪里