中间编写单元测试

单元测试是否完全是100％的交易？

我正在浏览旧项目并开始添加功能，这次是进行单元测试。但是，如果我要重新使用过去没有单元测试的组件，这最终将一文不值吗？

我是否需要为所有先前的类编写单元测试，而不必费神，还是只为要添加的新内容编写单元测试可以吗？

任何单元测试总比没有好。因此，这不是一个全有或全无的交易。

在您的情况下，由于测试驱动开发不是常态-您会想知道测试有什么用。

您想要确保将来编写的任何代码都不会破坏任何（当前）功能 -这就是子案例派上用场的地方。如果编写良好的测试通过，则您很可能没有损坏任何东西。接下来的开发人员将感谢您的测试和文档。

首先，如果您有一个分层良好的分层体系结构，请选择数据访问层并向上（朝着UI层）进行测试。如果项目具有域模型，则其最可能成为TDD的候选人，因为它可能具有大多数逻辑。如果服务（或业务逻辑）层只是在调用域/数据访问层，则没有必要以TDD方式进行服务层。这些是蓬松的测试，没有太大的价值。

添加到诸如Emma之类的代码覆盖率工具中，您可以稳定地监视总体测试覆盖率的提高。

我在一个非常大的代码库上工作，起初没有单元测试。通过遵循一些实践，我们现在（几年后）已使测试涵盖了大部分代码库。

所有新代码都必须具有单元测试。

所有更改的代码都必须添加了单元测试。

我们在不破坏旧代码的情况下安全地添加测试的方法主要是使用以下基本方法：

选择一小段您需要更改其功能的代码。

1. 尝试创建系统级集成测试以围绕代码。由于此级别测试的组合复杂性，因此这些测试将仅构成“冒烟”测试以拾取主要错误。

2. 介绍您需要的接口，以便能够测试您正在更改的代码。使用重构技巧（由您具有很高置信度的很小的更改序列组成）是正确的。尽可能尝试使用工具支持。例如，可以通过将要更改的方法移动/提取到其自己的对象上来执行此操作。定期检查您的更改，以便还原。定期查看修订控制历史记录，以同行评审您如何进行更改。

   尽量减少所需的更改，以打破妨碍您添加测试的依赖关系。

3. 编写测试以尽可能涵盖要更改的代码的功能。定期检查，并同行检查所有更改。
4. 为新功能/功能更改编写测试。
5. 实施功能（这是您的正常TDD周期）
6. 确保重构测试覆盖的区域（红色-绿色重构）。

我们发现这样做越多，越容易实现。每次您回到代码库时，它都会好一点。

我们已经看到，通过我们的质量检查测试人员的错误数量已大大减少。由于功能回归现在几乎是闻所未闻的，因此我认为值得我们付出努力。

（由于缺乏评论能力）我认为总比不进行测试要好。并非每个代码段都需要进行测试，而最终仅需要程序员使用。测试内部使用的实用程序功能很好，但是如果您以后通过干净的API访问所有内容，则不需要测试。

如果旧的东西已经工作了好多年，那么现在就不必强制创建单元测试，除非您更改旧的东西。无论如何，为新零件编写单元测试并不是毫无意义的。新零件是最有可能包含错误的零件，也是最有可能更改或重构的零件。

您可以开始介绍当前代码，如果有时间可以使用，请开始介绍旧代码的核心功能。您也可以要求PM额外的时间=）

单元测试是否完全是100％的交易？

绝对不！开始测试您要添加的新代码。即使这样做有些旧组件没有测试，您也会从中受益匪浅。当您必须处理其中一个组件或在其中发现错误时，请编写测试。随着时间的流逝，您将获得更多受测试的旧代码。