在“经常提前发布”环境中进行单元测试有什么意义？

在过去的一年左右的时间里，我带动了我的团队朝着经常提前发布的开发模式发展（又名：快速应用程序开发，而不是敏捷）。有关关闭构建方式的更多信息，请在此处查看我的答案： 一种提高RAD环境中发布质量的简单方法

当我们采用RAD时，人们是非常独立的，他们首先进行单元测试。集成测试发生在过程的后期。对于他们来说，这是自然的过程，无需太多正式的强制措施。现在情况大不相同了：

1. 整个平台与已建立的内部版本/发行版很好地集成在一起，可在客户端工作，没有任何热点。

2. 新功能需求不断涌现，我们会逐步构建它们。

3. 系统的整体动力非常重要，因为尽管独立的开发小组可能会正确地遵循流程，但由于复杂，非显而易见的情况而导致了重大故障。

4. 系统的许多部分都涉及新算法和研究投入，因此并非总是可以正确地预见到挑战（以及测试机制），例如在定义明确的软件中进行功能测试。

最近，我试图获得更好的整体情况，以查看我们是否需要改进流程。当我和我的团队坐下时，他们中的许多人都拒绝了：“我们不再进行单元测试了！” 而其他人则认为我们不应该立即开始，因为它将永远无效。

单元测试在相对成熟的系统中有用吗？我们是否至少需要根据单元的成熟度来权衡测试范围？单元测试会减慢开发速度吗？是否需要以其他方式评估单元测试？

在经常提前发布的环境中测试成熟平台的最佳实践是什么？

单元测试主要不是为了首先发现错误，而是为了确保系统的下一个版本与上一个版本一样稳定。发布周期越短，可以自动运行此测试而不是手动进行测试就越重要。

当然，如果您的系统具有一些独立的部分，并且您仅在系统的一小部分中在​​两个发行版之间进行操作，则可能会省略一些针对系统其他部分的单元测试。但是，您绝对应该对正在使用的零件使用（并扩展）单元测试。

另一件事是，随着系统的发展，对附加集成测试的需求将越来越大，但这并不意味着您将需要更少的单元测试。

您背后的真正问题也许是另外一个问题。由于系统越来越大，编写单元测试是否变得越来越难？您的“单元”测试是真的单元测试，还是不再单独测试？这可能是因为它们依赖于随时间推移而稳定的系统的较低层部分。

发生这些事情是因为开发人员倾向于通过直接引用现有库和代码来重用它们。由于单元测试通常必须提供更复杂的环境和更多的测试数据，因此通常会导致编写单元测试变得更加困难。如果这是您的问题，那么您应该了解关键概念Dependency Injection和Interface Segregation Principle，这可以帮助您使代码更易于单元测试。

您应该考虑研究测试驱动的开发，首先设计测试，并描述编写新代码时的工作方式。然后，您使测试通过。

以我的经验，这倾向于使代码更精简和思考，尤其是对于库，这是规范的可运行部分（意味着它将始终是正确的文档）。

就是说，现有测试用于确保代码仍按预期运行。它可以捕获代码损坏，并允许您确保第三方代码在升级时仍能按预期工作。

正如建议布朗博士和托尔比约恩Ravn的安徒生，一个早发布常释环境可以受益更多从优秀的单元测试和测试驱动开发不是一个长的发布周期。

如果您有一个良好的持续集成系统，并且可以很好地表示该功能的测试，那么您随时都可以知道什么在起作用（因为针对该功能的测试已经通过）以及尚未实现的功能（因为没有针对该功能的测试）。