推行TDD的思考

正文

请到「今天看啥」查看全文

这种测试带来的反馈总是慢于开发进度，一旦发现缺陷，修复缺陷的成本也会变得更高。

软件质量除了外部质量之外，内部质量同等重要。

软件成本等于开发成本与维护成本之和 ，而维护成本的增加主要归咎于内部质量的糟糕。

当我们让开发人员为原有代码编写单元测试时，总是觉得举步维艰，主因就在于代码的可测试性不够好。要测试一个类，竟然连简单创建它的对象都变成了不可能完成的任务。在为这样的代码编写单元测试时，就好像被落到了蜘蛛网中，被这些网丝牵住，缠住，如何挣扎都无法摆脱；除非，我们能够快刀斩乱麻。然而，一旦采用这种粗暴的方式，则对于系统而言，就不是维护，而是重写了。

测试先行的开发至少在一定程度规避了这样的问题。因为开发人员首先要写好测试，这就驱使开发人员必须强制地思考代码的可测试性。而在足够多的测试保护下，即使代码的内部质量欠佳，要进行重构也更为简单。

然而，这些好处都不是短期能见成效的，且团队若不能达成共识，只靠一二人坚定地践行TDD，在测试覆盖率不够的情况下，无异于杯水车薪。多数开发者在维护别人的丑陋代码时，可能会骂声连连，殊不知同时作为骂者自身，其实也在重复被骂者的故事。

2

需求分析与任务分解

需求分析能力常常是开发人员的短板。开发人员养成了一个习惯，看什么事情都会从技术实现的角度去思考。要实现一个网页，就会想到如何编写JavaScript来响应用户的动作，如何编写CSS，却很少思考用户体验和操作的流程。要完成一个数据分析，总会想到数据的属性，转换和提取数据的算法，却不会想到分析数据的价值以及合理的流程。

对于繁琐的需求描述，我们总是没有耐心去深入研读，而是在掌握了大体意思后，就开始匆匆进行开发与实现。 TDD要求我们在编写测试之前要做好合理的任务分解 。若没有很好地理解需求，任务分解就无法顺利进行。

这就带来了团队协作的问题。

若我们能从需求的源头进行改进，或许TDD会变得更容易。例如，对故事的拆分更合理，遵循User Story的INVEST原则，那么，要实现的Story在测试性、独立性方面就会有更好的改观。如果需求分析人员能够非常明确地编写出验收标准（Acceptance Cretiria），任务分解也会变得更加容易。

请到「今天看啥」查看全文