您花费多少时间进行单元测试？

在我曾经工作过的一家公司中，高管们坚持认为单元测试的代码覆盖率必须达到99％或更高。这导致编写的测试多于代码。从字面上看，我们花了3天时间为一个类编写测试，该测试花了一天的时间才能实现。

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

在我后来工作的公司中，单元测试是个未知数。这是以前有人听说过的东西。我努力地向他们介绍了单元测试的概念，但是没有效果。

现在，作为一名个体经营者，我想知道- 真正需要花多少时间进行单元测试？主要是iPhone / Android开发人员，测试中应覆盖哪些部分代码？

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

• 产品规模（项目越大，至少包含一些单元测试的需求越大）
• 所需的质量级别（如果您要尽快将需要尽快发布的软件组合在一起，并且可以接受一些小错误，那么您可能会被迫跳过某些测试，例如单元测试）
• 产品类型（可以对UI进行单元测试，但有时在项目的大量GUI部分上跳过单元测试而手动进行测试则更容易）
• 您的编码能力/历史记录（您通常会创建什么类型的错误？它们是单元测试通常会捕获的东西，还是其他类型的测试通常会发现的东西。知道这可能会促使您进行更多或更少的单元测试）

在我们的产品组中，我们的目标是单元测试的代码覆盖率达到50-70％，单元测试和测试自动化的覆盖率达到90％以上。对于编写每个单元的功能而言，通常花费在编写单元测试上的时间大约为1天，而这些功能需要3-4天的时间进行编码。但这可能因许多因素而异。

99％的代码覆盖率很棒。单元测试很棒。但是，仅单元测试的代码覆盖率就高达99％？我很难相信您可以从单元测试中获得如此多的覆盖。

对于您花3天为一个类编写测试，否则要花1天才能实现的情况。您没有详细说明为什么花这么长时间或共享任何代码。从推测的角度来看，我猜您不是在为您的班级编写真正的单元测试，而是在编写自动化测试。实际上，这没有什么不对-只要您能识别两种不同类型的测试之间的差异即可。

但是您说过，为期三天的测试写作只适用于一个班级。也许该类本身不是为单元测试而设计的。该类是否实现UI？联网？文件I / O？如果是这样，那么与与运行时交互的业务逻辑相比，您可能最终编写了更多的代码来测试Java运行时。

TDD让您思考接口和依赖关系的接口。可以将针对单个功能实现UI，网络和文件/ io的单个类更好地服务于多个类-一个用于网络，一个用于文件/ io，以及将UI分为模型查看器-控制器设计。然后，您可以使用依赖关系的简单模拟对象为每个对象实施适当的测试。当然，所有这些都花费更多的时间。因此，这种类型的设计可能需要3天的编码和1天的编写测试，而不是1天的编写代码和3天的编写测试。但是代码将具有更好的可维护性和可重用性。

单元测试将在维护时获得回报。如果您打算使用一个长寿的应用程序，那么您将花费比现在认为更多的时间来维护（如果您还没有尝试过，那么您将惊讶于一个成功的项目可以生存多长时间）

您想要的是，如果不小心更改了功能，测试就会中断，因此您会尽快找到这些东西。当功能意外更改时，客户会非常不喜欢。

如果您正在执行TDD，则将与​​代码同时编写测试，每隔几分钟（或更短的时间）在测试之间切换一次。测试不会花费任何时间。使用TDD可以更轻松地知道您具有可靠的测试覆盖范围。

如果事后进行单元测试，则需要编写测试，以告诉您代码是否由于更改而损坏。我不会在这里依赖覆盖率指标，而是会基于用例和公共接口的参数。这最终将取决于您的良好品味和经验。

如果您不花时间进行测试，那么您将花费更多的时间来调试实时代码。
因此，请花费尽可能多的时间进行测试，以覆盖全部（或99％的代码）。

正如其他人已经指出的那样，它很大程度上取决于软件的类型。您提到的3：1测试/开发时间比例对于一般项目而言可能有点过分，但对于任务关键型应用程序可能是完全可以的，而对于生命关键型系统则可能太少。

同样，对于普通应用程序而言，99％以上的单元测试覆盖率可能超出预期，但对于生命攸关的项目而言，覆盖率可能太低。

根据我的经验，考虑到生产代码的很大一部分是错误处理代码，对于大多数应用程序而言，覆盖80-90％的覆盖率就足够了，这可能需要花费与编写生产代码大致相同的时间。（然后再说一次，如果一个人认真地以TDD方式工作，则两者完全交织在一起，几乎变成一项任务，因此，一个人只能猜测实际比率。）