你在单元测试上花了多少时间？

Question

在一家我曾经为之工作的公司里，高管们坚持认为单元测试的代码覆盖率必须达到99%或更多。这导致编写了比代码更多的测试。我们花了3天的时间为单个类编写测试，这需要一天的时间来实现。

结果，我学到了很多关于TDD、测试工具、实践等方面的知识。

在我后来为之工作的公司中，单元测试是一件未知的事情。可能有人以前听说过。我很难向他们介绍单元测试的概念，但没有效果。

现在，作为一个自营职业者，我想知道--到底需要多少时间来进行单元测试？大多数是iPhone/Android开发者，在测试中应该涵盖哪些部分的代码？

Answer 1

所需单元测试的数量取决于以下几个因素：

• 产品规模(项目越大，至少需要包括一些单元测试)
• 所需的质量级别(如果您正在快速地将需要尽快发布的软件组装在一起，并且一些小的bug是可以接受的，那么您可能被迫跳过一些测试，比如单元测试)。
• 产品类型(UI可以进行单元测试，但有时更容易跳过项目的GUI部分的单元测试，而不是手动测试)
• 您的编码能力/历史记录(您通常创建哪种类型的bug？它们是单元测试通常捕获的东西，还是另一种类型的测试通常会找到的东西。了解这一点可能会促使您或多或少地进行单元测试)

Answer 2

单元测试在维护时得到了回报。如果你计划拥有一个长寿的应用程序，你将花费比你现在想象的更多的时间来维护(如果你还没有尝试过这一点，你会惊讶于一个成功的项目会持续多久)。

您想要的是，如果您意外地更改了您的功能，那么您的测试就会中断，以便您尽可能快地找到这些东西。当功能意外改变时，客户强烈不喜欢。

Answer 3

在我们的产品组中，我们的目标是从单元测试中获得50-70%的代码覆盖率，从单元测试和测试自动化组合中实现90%+覆盖。典型的编写单元测试的预算时间约为1天，因为每项功能都需要3-4天的低编码时间。但这可能会因许多因素而异。

99%的代码覆盖率很好。单元测试很棒。但是99%的代码覆盖率仅仅来自单元测试？我发现很难相信您可以从单元测试中获得如此多的覆盖率。

如果您花了3天的时间为一个类编写测试，否则需要花费1天的时间来实现。您没有详细说明为什么要花这么长时间或共享任何代码。根据推测，我猜您不是真的为您的班级编写了真正的单元测试，而是实际上是在编写测试自动化。事实上，这并没有什么错--只要你认识到这两种不同类型的测试之间的区别。

但你说三天的测试写作只适用于一节课。也许这个类本身不是为单元测试而设计的。类实现UI吗？联网？文件I/O？如果是这样的话，您最终可能会编写更多的代码来测试Java运行时，而不是与运行时交互的业务逻辑。

TDD让您从接口和依赖关系接口的角度进行思考。为单个特性实现UI、联网和file/io的单个类可能更适合分成多个类--一个用于网络，一个用于文件/io，UI分解为模型查看器-控制器设计。然后，您可以为每个测试实现适当的测试，并为依赖项使用简单的模拟对象。当然，所有这些都需要更多的时间。因此，这种设计可能需要3天的编码和1天的编写测试，而不是1天的代码编写和3天的编写测试。但是代码将具有更好的维护性和可重用性。