为什么不针对internal接口写单元测试?

测试驱动的开发(TDD,Test Driven Development)的核心理念,是要使得重构(refactoring)更为有效,而不是创建更多的测试。

对一个有着长生命周期的项目来讲,在它的第一个版本,通常具有好的、干净的架构。随着版本的不断更新,会引入越来越多旁门左道的变通方法(hacky workaround)、捷径(short cuts)、不一致的接口(inconsistent interfaces)、难以理解的契约(confusing contracts)等,这样项目就会变得越来越难以维护(尤其是我们的那些已经过时的代码)。那么,怎么能够避免这种情况的出现呢?关键就是,项目代码要具备能够自由重构而不引入回归(regression)的能力。测试驱动的开发提供了这种能力。

基于这样的理解,我们应该将单元测试写成是代码重构的工具。什么意思呢?测试用例的首要原则:当重构代码的时候,不应该改变单元测试

考虑相反的情况,当我们试图去重构项目代码时,修改了一些单元测试依赖的接口。因此我们需要同步地修改单元测试的代码。那么我们怎么才能确定在单元测试中没有产生regression?这样的单元测试,不但不能够帮助进行代码重构,反而成为了一种负担。这也是我们很多已过时的测试存在的问题:当我们改变源代码,需要花费很多的时间去更新测试。

这就是为什么最佳实践之一是“只针对公共接口(public interface)写单元测试”的原因。公共接口通常是要相对更加稳定的(否则会影响到用户)。如果单元测试针对internal接口,重构的时候要么不去改变这些接口,要么就必须同步修改测试代码。

你可能感兴趣的:(intern)