集成测试对单元测试的依赖:构建JUnit集成测试的好策略/致命的不可实现策略？

Question

我正在工作的系统已经(幸运地)进行了JUnit单元测试，这些测试涵盖了一定百分比的代码功能(我想，总比没有好)。

系统中的方法是高度依赖的，可以作为输入发送给方法的参数的组合是巨大的。让我们看看一个例子：

public void showMessage (final Language language, final Applications apps, final UserID userId)

根据不同的应用程序和userIds，上述方法可以弹出300,000多个不同的消息框。除了对单一方法施加如此巨大的压力--至少其中几种方法--听起来是否可行(而国际海事组织( IMO )在设计上是不合理的)之外，我们还遇到了对可能造成巨大问题的漏洞的恐惧。

话虽如此，我们所发现的只是如下：

1. 重构JUnit单元测试
2. 提取方法中的许多对象作为参数。
3. 创建对象工厂
4. 用工厂创建的不同输入来输入单元测试(可能是蛮力测试？)
5. 检查新重构测试的结果。

因此，基本上，问题如下：

在单元测试之上创建集成测试:可能性和挑战？这是一种定制的方法还是一种rational标准方法？在哪里可以将这些测试放在项目文件和项目构建生命周期中，是否应该一直构建它们以完成构建过程？

任何类型的反馈/评论，来自JUnit实现的限制和设计/想法的限制。

Answer 1

集成测试的全部目的是验证组件是否正确地交互在一起。每个单元测试都应该验证代码中的一个原子部分。一般经验法则(根据我的经验)，如果单元测试大于10行代码，那么这当然不包括驻留在@Before/@After块中的测试的一部分代码。单元测试的另一件事是，它们可以使不依赖于任何其他作为集成测试的依赖项。我不会使用您前面描述的方法，因为单元测试将使用静态数据。这在回归测试中也起了很大的作用，在回归测试中，旧的单元测试迁移到了在发布前执行的回归套件中。

您的集成测试将依赖于诸如DBUnit、Selenium等项，需要依赖数据库或GUI来执行/验证。单元测试应该在开发人员执行签入之前运行。集成测试应该在每次发生更改时运行(或者不管您对潜在错误的容忍度如何，一天一次就太少了)。

同样，我建议在单元测试中针对动态数据使用。主要是因为断言可能失败，但它不能证明单元测试是无效的。

更新

嗯，就像我说的，我认为这是一个集成测试。我不确定的是，在集成测试中，您是在测试系统的链，而不是那些系统的单元测试！单元测试和集成测试之间的依赖也是一个问题，IMO！

回复：

您对单元测试副集成测试有一个基本的误解。单元的代码，即函数没有任何依赖，如果它们做了，您的架构需要一个认真的大修。通过集成测试，您必须构建不同的场景，以证明两个不相交的模块相互交互。这并不意味着将两个单元测试的逻辑组合成一个“集成”测试。

Answer 2

埃米尔

你所说的“单元测试之上的集成测试”是什么意思？我会看到集成测试是粗粒度的黑匣子测试，测试部署在服务器上的应用程序，与真正的db、JMS队列、第三方see服务等对话。通常，您可能希望模拟您不拥有的基础设施(比如第三方see服务等)。

集成测试将比单元测试慢得多，因此您不会倾向于在每次构建时执行它们。如果您像jenkins一样使用CI服务器，您可能会创建一个单独的集成构建，它将执行您拥有的所有测试(单元+集成)。

您在单元测试中提到了动态数据。我认为让具有静态输入数据的单元测试确保它们每次执行时都包含相同的执行路径，验证在引入新代码时是否发生了任何行为更改，或者测试一些角情况是好的.

但是..。

还有一个好主意，那就是有一套额外的测试来强调你的应用程序的随机输入数据。AFAIK，Lucene/Solr的人采用了这种方法，他们甚至为随机测试提供了自己的框架。看看这些链接：

http://labs.carrotsearch.com/randomizedtesting.html

http://vimeo.com/32087114

至于如何使用遗留软件的一般方法，我推荐M. Feather的“有效地使用遗留代码”。优秀的书，它可能会给您一些想法，如何用单元测试覆盖您现有的代码，并提高代码质量。

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052