单元级测试、敏捷和重构

Question

我正在开发一个非常敏捷的开发系统，一小部分人都是我自己做的。

我已经进入了测试阶段，并发现自己编写的大部分是功能级测试，理论上应该留给测试人员(实际上，我不需要entirely...trust我们的测试人员来检测和识别缺陷，让他成为功能测试的唯一编写者)。理论上，我应该写的是单元级测试。

不过，我不确定这笔钱是否值得。单元测试需要一段时间，比功能测试还要长，因为我必须将模拟和插件安装到非独立运行的较小单元中。更重要的是，我发现我对代码进行了大量的重构和重新设计--这部分是由于我继承的代码需要进行大量的重新设计，并且仍然在被清理，但是即使我完成了需要工作的部分，我确信在扩展代码的过程中，我仍然会做大量的重构和重新设计。我感觉好像我要破坏我的单元测试，迫使浪费的时间来重构它们，通常是由于单元测试，根据定义，必须与代码结构紧密耦合。

当功能测试(当我重构/重新设计时永远不会中断)应该找到大多数缺陷时，So.is值得浪费所有的时间吗？单元测试真的通过功能提供了那么多额外的缺陷检测吗？如何创建一个很好的单元测试，这些测试可以使用非常快速和敏捷的代码进行快速修改？

ps，我会很满意的链接到任何一个人认为是一个优秀的资源，如何‘做’在一个高度变化的环境中的单元测试。

编辑:为了澄清我正在做一些非常不正式的TDD，我似乎只是在编写测试，测试的内容应该是功能级而不是单元级。我认为这部分是因为我拥有几乎所有的项目，我觉得我不需要限制它的范围；部分原因是，想要返回并追溯添加所需的单元测试以覆盖足够多的代码，这样我才能轻松地测试一个没有完整功能的单元，并且相信该单元仍然与其他单元一起工作是一件令人畏惧的事情。

Answer 1

啊..。你绝对不是在做TDD。TDD是测试驱动的设计，特别是它首先编写规范(也称为测试)。您要做的是编写测试(这很好，而且通常非常有用--毕竟，我们需要测试代码，只是我们大多数人都可以手动编写)。

至于单元测试和功能测试，在我看来，“大量重构和重新设计”是单元测试的主要好处。我喜欢得到的代码比我开始时设计得更好。不幸的是，这种努力是否合理是相当主观的。

我不会专注于“试图返回并追溯添加覆盖足够多代码所需的单元测试”；试着在您认为足够复杂的功能块周围添加测试，以证明这一点是值得的。我有一个特殊的例子，我必须添加测试，因为我正在处理的项目中的一个视图中有很多逻辑来显示正确的时间，这取决于市场和时区。它不是TDD --生产代码已经存在了--但是我想确保它在我能想到的各种情况下都能正常工作。我不认为除了不断变化的业务需求之外，这些测试也不需要更改。

最后，我将指向强制性的"有效地使用遗产代码“引用。