unit-testing - 自动化单元测试与自动化集成测试的优缺点是什么？

Question

最近我们一直在向我们现有的 Java 应用程序添加自动化测试。

我们有什么

这些测试中的大多数是集成测试，它们可能涵盖一系列调用，例如:-

HTTP 发布到 servlet

servlet 验证请求并调用业务层

业务层通过 hibernate 等方式做一些事情并更新一些数据库表

servlet 生成一些 XML，通过 XSLT 运行它以生成响应 HTML。

然后，我们验证 servlet 是否以正确的 XML 响应，以及数据库(我们的开发 Oracle 实例)中是否存在正确的行。然后删除这些行。

我们还有一些较小的单元测试来检查单个方法调用。

这些测试都作为我们每晚(或临时)构建的一部分运行。

问题

这看起来不错，因为我们正在检查系统的边界:一端是 servlet 请求/响应，另一端是数据库。如果这些工作，那么我们可以自由地重构或处理中间的任何事情，并且有信心被测试的 servlet 继续工作。

使用这种方法我们可能会遇到什么问题？

我看不出在单个类上添加更多单元测试会有什么帮助。这不会使重构变得更难，因为我们更有可能需要丢弃并重新编写测试吗？

Answer 1

您在问两种不同事物的利弊(骑马与骑摩托车的利弊是什么？)

当然，两者都是“自动测试”(~骑行)，但这并不意味着它们是替代品(您不会骑马数百英里，也不会在封闭的车辆泥泞中骑摩托车地方)

单元测试 测试代码的最小单元，通常是方法。每个单元测试都与它正在测试的方法密切相关，如果它写得很好，它(几乎)只与它相关。

它们非常适合指导新代码的设计和现有代码的重构。它们非常适合在系统准备好进行集成测试之前很久就发现问题。请注意，我写了指南，所有的测试驱动开发都是关于这个词的。

手动单元测试没有任何意义。

重构呢，这似乎是您主要关心的问题？如果你只是重构一个方法的实现(内容)，而不是它的存在或“外部行为”，单元测试仍然有效并且非常有用(在你尝试之前你无法想象它有多大用处)。

如果您正在更积极地重构，改变方法的存在或行为，那么是的，您需要为每个新方法编写一个新的单元测试，并可能丢弃旧的。但是编写单元测试，特别是如果你在代码本身之前编写它，将有助于澄清设计(即 方法应该做什么，和 什么 不应该)被实现细节弄糊涂了(即 如何 方法应该做它需要做的事情)。

自动化集成测试 测试代码的最大单元，通常是整个应用程序。

它们非常适合测试您不想手动测试的用例。但是您也可以进行手动集成测试，它们同样有效(只是不太方便)。

今天开始一个新项目，没有单元测试没有任何意义，但我想说，对于像你这样的现有项目，为你已经拥有的所有东西编写它们并没有太大意义并且它正在工作。

在您的情况下，我宁愿使用“中间地带”方法写作:

较小的集成测试，仅测试您要重构的部分。如果您要重构整个事情，那么您可以使用当前的集成测试，但是如果您只重构——比如说——XML 生成，那么要求数据库的存在没有任何意义，所以我会写一个简单小巧的 XML 集成测试。

您将要编写的新代码的一堆单元测试。正如我在上面已经写过的，一旦你“搞乱了中间的任何东西”，单元测试就会准备好，确保你的“乱七八糟”在某个地方。

事实上，您的集成测试只会确保您的“困惑”不起作用(因为一开始它不起作用，对吗？)但它不会给您任何线索

为什么它不起作用

如果您对“困惑”的调试确实是在解决某些问题

如果您对“困惑”的调试破坏了其他东西

如果整个更改成功，集成测试只会在最后给出确认(并且很长一段时间内答案都是“否”)。集成测试不会在重构过程中为您提供任何帮助，这会使重构变得更加困难并且可能令人沮丧。你需要单元测试。