遗留代码加单元测试的原则思考

TDD的理想并不是每一个人都有幸实现，日常工作中更多是为遗留代码增加单元测试，以便后续进行修改和重构。

为遗留代码增加单元测试，我推荐下面的四化原则：

• 收益最大化
• 成本最小化
• 设计最优化
• 安全适度化

###收益最大化

所谓，收益最大化，就是要求我们在增加单元测试的时候，不要片面的追求高覆盖率，要考虑投入和产出，时刻记住我们增加单元测试的目的和本心：增加对软件产品内建质量的信心，提升软件产品的需求响应力。

所以，有两句话很有用。

• Not Test Everything.
• Test The Most Changing Things.

说白了就是别瞎测，想着将所有的代码都加上单元测试，这非常的不经济。要测试那些未来改动的可能性大的代码。不要去测那些一年两年都不可能去改动的代码。当然，这里的改动的可能性指的是对需求的正确的响应情况下改动的可能性和很多由于不敢改，而导致代码不会改动是两回事。

###成本最小化

对代码添加自动化测试是有成本的，特备是为了测试要进行Mock、Stub或者Fake的情况。所以，有这样一个说法叫做：Not Mock Everything.

如果测试的过程中需要增加大量的Mock等测试辅助才能进行，就需要思考一下，这样的成本投入是否值得，是否有其他的方法可以降低这个成本。其中最常见到的情况就是，适当的调整生产代码，以便于其更加易于测试。

###设计最优化

对遗留代码添加单元测试过程中，难免会出现生产代码需要增加大量的Mock等辅助手段，甚至难于测试，比如没有返回值、依赖于外部文件等。这个时候，实际上就是测试代码驱动生产代码进行设计优化和演进的时候。采取正确的态度、原则和方法可以在单元测试的添加过程中让代码的设计逐渐优化。但是，生产代码修改要遵循安全适度化的原则。

###安全适度化

面对遗留代码增加单元测试的时候，有一种观点认为增加单元测试的时候，不应该修改生产代码，应该增加了之后，保证了覆盖率在进行重构和修改；另一种观点认为，生产代码之所以难于测试，正是进行修改、重构和设计提升的机会，应该趁机，在增加单元测试的同时进行生产代码的优化和改进。

对遗留的生产代码添加单元测试，在进行生产代码的修改方面，应遵循安全适度的原则，即在生产代码最小改动的情况下，增加单元测试，具体内容如下：

• 没有单元测试覆盖的情况下，生产代码也是可以改动的
• 没有单元测试覆盖的情况下，生产代码的改动每一步都应该只改动尽量少的代码
• 没有单元测试覆盖的情况下，生产代码的改动应该使用IDE重构工具进行