Junits应该涵盖哪些类型的案例，Cucumber应该涵盖哪些类型的案例

Question

开发人员通常使用 Junits

编写测试用例

测试人员通常使用黄瓜

编写测试用例

我很困惑，这些（Cucumber和Junit）有什么不同，如果最后都是为了验证我们代码的逻辑！

我的假设是否正确？

• 简单方法测试由Junits完成

• 艰难的情况，我们有黄瓜

Answer 1

顾名思义，

单元测试旨在测试小型代码单元。单元测试是用代码编写的，这使业务对它的可读性降低，但使其功能非常强大，并且可能非常快。

黄瓜是用于描述行为的工具。每个库克将exercise RewriteCond %{REQUEST_URI} /index.php RewriteRule ^(.*)index\.(php)$ https://%{SERVER_NAME}/$1 [R=301,L] 更大的代码块。

这两种测试非常不同。差异如此之大，以至于大多数黄瓜爱好者不想使用单词test（https://cucumber.io/blog/collaboration/the-worlds-most-misunderstood-collaboration-tool/）

场景完全与验证代码的逻辑无关，它们与代码无关。它们用于描述应用程序的行为并支持该行为的开发。方案和行为实施后，它们用于确认行为“可能”仍按预期工作。

单元测试都是关于代码的，它们是用代码编写的，并且（理想情况下）直接连接到代码。它们绝对可以用于验证代码的逻辑。

还有其他一些主要区别

运行时

• 场景很慢
• 单元测试速度很快（除非它们写得不好）

差异不小。最佳书面单元测试可以比最佳书面方案快1000倍。

表现力和力量

• 场景使用自然语言来表达自己。他们使用抽象和命名来行使权力。编写得当的加油书对企业来说很可读

• 单元测试使用代码来表达自己并发挥作用。它们功能更强大。但是，这对他们来说很难表达自己。利益相关者无法阅读单元测试。对于非编码人员来说，即使编写精美的单元测试的输出也很难阅读

摘要

使用不同的工具（自然语言与代码），您有两种截然不同的东西，它们以不同的方式工作。因此，拥有不同的工具也就不足为奇了。

不幸的是，我们有很多人使用Cucumber作为测试工具来编写像测试这样的单元，并且我们有很多人使用单元测试工具来编写用于测试大量代码的慢速测试。这两件事都是可能的，甚至是可行的，但远非最佳。

Answer 2

黄瓜是一种行为驱动设计（BDD）框架。您可以在其中检查一段代码的行为。

JUnit是较低级别的“单元测试”工具，允许开发人员测试代码的每个可能部分。

为了更清晰，您可以选择Cucumber vs Junit。

Answer 3

所以，我举一个例子，解释黄瓜与Junit的域名之间的区别

考虑Web应用程序的示例。

• Junits将测试Controller，Service和DAO层所涉及方法的代码逻辑

此应用程序的

• 黄瓜测试将承受具有各种REST请求的案例，此案例由该应用程序的API公开。 [根据情况，每个请求都有针对Get，Post，Put，Delete的测试请求，并带有多个数据]