JUnit 4 vs TestNG - 更新 2013 - 2014 [关闭]

Posted 2023-02-16

【中文标题】JUnit 4 vs TestNG - 更新 2013 - 2014 [关闭]

【英文标题】：JUnit 4 vs TestNG - Update 2013 - 2014 [closed]

【发布时间】：2012-12-17 16:28:56

【问题描述】：

JUnit 4 和 TestNG 曾经具有可比性。两种测试框架的优缺点是什么？

【问题讨论】：

如果您正在查看功能比较，mkyong 在 jUnit 4 Vs testNG 上有一个good article 如果您想参考使用比较。 Kapil 希望有一个nice article 有帮助！

我发现这样的问题对 SO 非常有帮助...我想说谢谢你冒着风险问它，并祝贺它没有关闭！

时隔多年再次看到这个问题。有趣的是——我闻到了阴谋的味道！我的问题完全集中在不同的功能上，然后有一个“社区”编辑将我的问题编辑为“利弊”，然后由于基于意见而关闭了问题。 Lmao。

【参考方案1】：

我今天比较了 TestNG 和 JUnit4，我可以指出我在测试框架方面的有限经验的主要优势是，TestNG 使用数据提供者概念处理参数化测试的方式更加优雅。

据我所知，对于 JUnit4，您必须为要测试的每组参数创建一个单独的测试类（使用 @RunWith(Parameterized.class) 运行）。使用 TestNG，您可以在单个测试类中拥有多个数据提供者，因此您也可以将单个类的所有测试保存在单个测试类中。

到目前为止，这是我唯一可以指出 TestNG 优于 JUnit4 的地方。

Intellij IDEA 包括对 TestNG 和 JUnit 的开箱即用支持。但是，Eclipse 仅支持开箱即用的 JUnit，需要安装一个 TestNG 插件才能使其工作。

但是，我在使用 TestNG 时遇到的一个更烦人的问题是，如果您使用 PowerMock 来模拟测试中的依赖项，那么您的测试类需要扩展 PowerMockTestCase。显然，有一些方法可以通过特殊方法或testng.xml 套件定义来配置您的测试框架在使用 PowerMock 时需要了解的对象工厂，但目前这些方法似乎被破坏了。我不喜欢让测试类扩展测试框架类，这似乎很老套。

如果您不使用 PowerMock，这当然不是问题，但总而言之，我觉得 JUnit4 得到了更好的支持。

【讨论】：

并不是说有参数化测试的替代实现，例如code.google.com/p/junitparams 如果你不喜欢它们中的任何一个，你可以编写自己的——这就是我喜欢 JUnit 的可扩展性的地方。 ;)

【参考方案2】：

根据我对这两个框架的经验，testng 有一些方便的功能，JUnit 团队多年来一直拒绝实施这些功能。出于这个原因，我更喜欢它而不是 JUnit。转换为 testng 很容易，因为它基本上支持 JUnit 中的几乎所有内容（甚至还有一个用于 eclipse 的转换器插件），由于缺少这些功能，转换回 JUnit 并不是那么好。

在 testng 中，@BeforeClass 方法不是静态的，并且在该类中的测试运行之前执行，而不是在加载测试类时执行（JUnit 行为）。我曾经有一个 JUnit 项目，其中所有的数据库测试（几十个）一开始就初始化了数据库，这是非常愚蠢的行为。在 JUnit 社区中，对此有很多支持和反对的争论。它的要点是每个测试方法都应该有自己的测试夹具，因此你不应该有一个非静态的 beforeAll 样式方法，因为这将允许你偷偷地设置一个实例变量，然后在你的所有测试中使用它。有效，但对于集成测试来说真的很烦人。 TestNG 在这里为用户提供了选择。根据设计，Junit 没有，这很烦人。

Testng 数据提供者比等效的 JUnit 更灵活一些。您可以为每个测试指定哪个数据提供者方法应该提供输入，而不是像在 JUnit 中那样为整个类采用一种适合所有方法的方法。因此，您可以在一类中为您的测试提供正面和负面案例数据提供者。很高兴拥有。

你可以在 testng 中用@Test 标记一个类，这意味着：每个公共方法都是一个测试。在 Junit 中，您需要在每个方法上复制/粘贴 @Test。

hamcrest 与 JUnit 捆绑的方式和 JUnit 与 testng 捆绑的方式是两者的烦恼。 maven 中有没有这个问题的替代 jars。

我对这两个框架的最大担忧是它们似乎都停止了发展。发布的频率越来越低，并且往往具有越来越少的值得注意的功能。例如，整个 BDD 运动似乎对这两个框架都没有什么影响。此外，JUnit 可以简单地采用我上面列出的大部分内容。 JUnit 不能实现这些东西并没有很好的技术原因； JUnit 背后的人只是选择不实现这些东西。这两个项目似乎也缺乏对未来方向的愿景，而且他们似乎很乐意在过去几年中进行一些细微的调整。

【参考方案3】：

我一直在寻找将 TestNG 切换到 JUnit 的充分理由，我发现 this 幻灯片 Tomek Kaczanowski 很好地解决了这个问题。 Tomek 是Practical Unit Testing 的作者，这本书似乎很受开发人员和测试人员的尊重。

【参考方案4】：

如果您从事 Java/Scala 项目并且 Gradle 是您选择的构建工具，请记住 ScalaTest 框架只有 JUnitRunner 来运行您的 scala 测试。换句话说，您可以选择：

Java JUnit 测试 + Scala 测试使用 JUnitRunner 运行 => 更好的 Gradle 集成 Java testNG 测试 + Scala 测试使用 Scala Runner 运行 => 较差的 Gradle 集成，因为从 Gradle 的角度来看，scala 测试运行器是单个批量任务。

【参考方案5】：

您可以使用 Mockito 作为您的模拟框架。它与 TestNG 很好地集成。您无需扩展任何类即可将 Mockito 与 TestNG 一起使用。通过这种方式测试代码的耦合度较低，如果出于任何原因需要使用其他模拟框架，这样做很容易。

【讨论】：

这个答案与问题完全无关......

@AdrianShum 我认为 Konrad 试图评论 JeroenHoek 关于将 PowerMock 与 TestNG 集成的观点，因为他似乎没有“评论”特权，我认为他将评论作为答案跨度>

这个答案误解了 PowerMock 是什么。它不是 Mockito 的替代品，而是允许 Mockito 模拟某些 Mockito 单独无法完成的事情（静态方法、最终类）的补充。

【参考方案6】：

简而言之..

如果您的范围仅限于精细的单元测试，它们之间没有依赖关系，那么可以使用 JUnit。

如果您的范围需要功能测试，可能/可能不需要测试之间的依赖关系和数据（参数）共享，那么选择 TestNG。此外，TestNG 可以进行类似于 JUnit 的单元测试。所以你可以拥有一套单元测试和一套功能测试。