为什么黄瓜被认为是集成测试工具而不是单元测试工具？

Question

这一直困扰着我.为什么人们说在rspec中进行单元测试而在黄瓜中进行整合测试？我不是在问为什么这些测试是必要的 - 我知道集成和单元测试之间的区别.我只是不明白为什么,鉴于黄瓜完全可定制的语法,它不用于单元测试？

在我看来,为黄瓜和rspec编写相同数量的代码,唯一的区别是,对于黄瓜,您将测试逻辑与测试编写分开.

Answer 1

使用黄瓜进行单元测试有很多开销.您不仅要编写功能,还要使用单独的代码将它们映射到实现.

单元测试意味着写入速度非常快,执行速度非常快.当然,黄瓜专注于最终用户体验,主要是由于编写功能时使用的语言.

要刷新,功能将包含以下内容:

作为系统的一些利益相关者,
我想进行一项活动
,以便我可以从中获得一些好处

Given a precondition
When I perform an action
Then something should happen

通常被忽略的开头段落非常重要,因为它为操作设置了上下文并解释了为什么会发生某些事情.由于使用了自然语言,这些东西很容易向非程序员展示,以获得一些反馈.

现在,使用这些进行单元测试似乎充其量只是尴尬.首先,最终用户关注建议采用更多集成方法,因为该功能没有提及模拟和UI /逻辑分离.即如下所示的功能似乎很奇怪:

Given a that a database mock is configured with the following data
| ID  | Username |
| 0   | igor     |
When call FindAll on User Repository
Then I get the following user back
| ID  | Username |
| 0   | igor     |

此外,随着您的SUT变小(即一个类),操作的上下文并不重要.用户存储库不关心上下文,例如,它不关心它的消费者是普通用户还是VIP用户.一个简单的组件(它应该是SRP之后),根据其输入完全确定.

因此,单元测试用于验证您编写的内容是否正确,并且使用cucmber测试来验证您编写的内容是否通过将系统的行为置于上下文中来满足更高的目的.

Answer 2

黄瓜解决了一系列特定问题 - 吸引那些无法轻松阅读代码但无法编写代码的业务利益相关者,并在自动化方案中的步骤之间提供重用.这些方案通常还涵盖行为的多个方面,记录整个系统的功能,并且通常涵盖跨多个组件的整个用户旅程.Cucumber鼓励的基于步骤的体系结构是处理这些场景的理想选择.

它还介绍了一整套其他问题.首先,您需要将Cucumber场景与一组灯具联系起来,因此还有另一层抽象,这使得它们的写入速度变慢.其次,英语比代码更难重构 - 即使是像Ruby这样的动态语言(差异在C#和Java变种中更为明显,如JBehave,SpecFlow,Cuke4Nuke和Cuke4Duke).很难判断步骤是否仍在使用,并且更难以维护方案.在各个步骤之间管理状态也更加困难.

通过单元测试,观众是技术性的.理想情况下,类具有单一职责,几乎没有重复,因此重用步骤并不重要.当我们想要更改代码元素时,我们倾向于寻找其命名约定与文件或类匹配的测试,因此使用这些测试的一对一映射是理想的.

由于Cucumber的开销,并且因为我们没有从Cucumber提供的优势中获得价值以换取其开销,RSpec更适合单位级别的行为.(对于JUnit,NUnit等也是如此)

如果您错过了Cucumber的"Given,When,Then",请尝试将它们添加为注释.这对我很有用.