【发布时间】：2020-09-13 14:55:52
【问题描述】：
开发人员通常使用 Junits
编写测试用例测试人员通常用Cucumber
编写测试用例我很困惑，这些（Cucumber 和 Junit）有什么不同，如果最后，两者都是为了验证我们代码的逻辑！
如果我说……我的假设是否正确？
简单的方法测试由 Junits 完成
艰难的场景，我们有 Cucumber
【问题讨论】：
标签： java testing junit cucumber
【发布时间】：2020-09-13 14:55:52
【问题描述】：
单元测试，顾名思义，旨在测试小代码单元。单元测试是用代码编写的，这降低了业务的可读性，但也使其非常强大并且可能非常快。
Cucumber 是一个用来描述行为的工具。每个 cuke 将exercise 一大块代码。
这两种测试非常不同。如此不同以至于大多数 Cucumber 爱好者都不想使用测试这个词 (https://cucumber.io/blog/collaboration/the-worlds-most-misunderstood-collaboration-tool/)
场景根本不是关于验证代码的逻辑，它们与代码无关。它们是关于描述您的应用程序的行为并支持该行为的开发。在场景和行为实施后，它们用于确认行为“可能”仍在按预期工作。
单元测试都是关于代码的，它们是用代码编写的，并且（理想情况下）直接连接到代码。它们绝对可以用来验证代码的逻辑。
还有一些其他的主要区别
运行时
- 场景很慢
- 单元测试很快（除非写得不好）
这不是一个小区别。优化编写的单元测试可以比优化编写的场景快 1000 倍。
表现力和力量
场景使用自然语言来表达自己。他们使用抽象和命名来行使权力。写得好的杯子对企业来说非常易读
单元测试使用代码来表达自己并发挥作用。他们更强大。然而，他们更难表达自己。利益相关者无法阅读单元测试。即使是编写精美的单元测试的输出对于非编码人员来说也很难阅读
总结
你有两个非常不同的东西，以不同的方式工作，使用不同的工具（自然语言与代码）。所以你有不同的工具也就不足为奇了。
不幸的是，我们有很多人使用 Cucumber 作为测试工具来编写类似单元的测试，并且我们有很多人使用单元测试工具来编写测试大量代码的慢速测试。这两件事都是可能的，甚至可能是可行的，但它们远非最佳。
【讨论】：
-
很好解释。根据答案和更多的实际工作，我也在下面提出了一个答案。请检查我的理解是否正确。谢谢！
Cucumber 是一个行为驱动设计 (BDD) 框架。您可以在哪里检查一段代码的行为。
JUnit 是一个较低级别的“单元测试”工具，允许开发人员测试代码的每个可能部分。
您可以选择Cucumber vs Junit 以获得更清晰的信息。
【讨论】：
所以，我举个例子，解释一下 Cucumber 和 Junit 的域之间的区别
考虑一个 Web 应用程序的例子..
Junits 将测试 Controller、Service 和 DAO 层所涉及方法的代码逻辑
此应用程序的 Cucumber 测试，将承受具有各种 REST 请求的情况，由该应用程序的 API 公开。 [它将有 Get、Post、Put、Delete 的测试请求，每个请求都有多个数据，视情况而定]
【讨论】：
-
您对单元测试是正确的。特性和场景确实应该在更高的抽象级别上编写。假设您的应用程序可以让用户注册（注册）。您的场景应该是
When I register而不是When I send a Post to the registration endpoint。你如何注册在场景中没有位置，它应该被推到称为步骤定义的辅助方法中。即使通过 API 进行交互，这也适用