TW洞见 | 张逸：推行TDD的思考
TW洞见 | 张逸：推行TDD的思考
目前来看，推行TDD的障碍大约有如下几点：
- 开发人员的质量意识；
- 分析需求并进行任务分解的能力；
- 将测试作为开发起点的开发习惯；
- 开发人员的重构能力，包括如何识别坏味道和如何运用重构手法；
- 单元测试的基础设施，尤其是测试数据准备；
开发人员的质量意识
开发人员对于软件质量，常常偏重于软件的外部质量，体现在他们的工作效益上，就是被测试人员发现的缺陷数。而惯常的软件开发思想，总是认为开发人员不适合做 测试，因为他们总是站在自己的角度去看待问题，从而可能忽略真正需要测试的用例。这种思想给了开发人员一个错误信号，认为自己不应该写测试，即使写了测 试，也写不好。殊不知，由开发人员编写测试带来的收益，最重要的一点不在于测试本身，而在于它能促进开发、测试以及需求分析人员的交流与沟通。而测试先行 的方式也能让开发者跳出实现的窠臼，而从业务角度去看待问题，从消费者角度去思量接口。此外，由于开发者总是惫懒地将测试职责委派给了专门的测试人员，于 是渐渐会产生一种依赖心理。测试人员的精确测试当然可以保障质量，但这种测试通常是黑盒测试，这里保障的质量主要还是外部质量。而且，这种测试带来的反馈 总是慢于开发进度，一旦发现缺陷，修复缺陷的成本也会变得更高。
软件质量除了外部质量之外，内部质量同等重要。软件成本等于开发成本与维 护成本之和，而维护成本的增加主要就归咎于内部质量的糟糕。这里讲的内部质量包括：代码的可读性、可重用性、可扩展性等。当我们让开发人员为原有代码编写 单元测试时，总是觉得举步维艰。分析原因，主要问题在于代码的可测试性不好。要测试一个类，竟然连简单创建它的对象都变成了不可能完成的任务。我们为这样 的代码编写单元测试，就好像在触及蜘蛛网，一旦被这些网丝给牵住，缠住，就可能无法摆脱。除非我们能够快刀斩乱麻，那对于这个系统而言，就不是维护，而是 重写了。测试先行的开发至少在一定程度规避了这样的问题。即使代码的内部质量仍有所欠缺，但在足够覆盖率的保护下，我们要进行重构也变得更为简单。
然而，这些好处都不是短期能够见到成效的，且团队若不能达成共识，只靠一二人坚定地践行TDD，在测试覆盖率不够的情况下，改进仍然有限。多数开发者在维护别人的丑陋代码时，可能会骂声连连，殊不知同时作为骂者自身，其实也在重复被骂者的故事。
我不是说没有采用TDD，代码质量就一定不高；但我可以说采用了TDD，代码质量至少有了可以改进的基础。
分析需求并进行任务分解的能力
需求分析能力常常是开发人员的短板。开发人员养成了一个习惯，看什么事情都会从技术实现的角度去思考。要实现一个网页，就会想到如何编写 JavaScript来响应用户的动作，如何编写CSS，却不会去思考用户体验和操作的流程。要完成一个数据分析，总会想到数据的属性，转换和提取数据的 算法，却不会想到分析数据的价值以及合理的流程。
而且对于繁琐的需求描述，我们总没有耐心去深入研读，而是会在掌握了大体意思后，就开始匆匆进行开发与实现。TDD要求我们在编写测试之前要做好合理的任务分解。若没有很好地理解需求，任务分解就无法顺利的进行。
这就带来了团队协作的问题。若我们能从需求的源头上进行改进，或许TDD会变得更容易。例如，我们对故事的拆分更合理，较好地遵循了User Story的INVEST原则，那么我们所要实现的Story在测试性、独立性方面都会有很好的改观。如果BA能够非常明确地编写出验收条件 （Acceptance Cretiria），进行任务分解就变得更加容易了。
更进一步，若BA能够参考甚至遵循 Specification By Example，并采用Given-When-Then的模式来描绘各个用例场景，再要进行任务分解，不就变得轻而易举吗？因此，有时候推行TDD非常艰 难，或许最大的原因是我们仅仅将目光放到了开发者身上，而忽略了BA扮演的关键角色。正所谓：问渠那得清如许，为有源头活水来。
我一直强 调任务分解是有层次的。分析需求时，不能一个猛子就扎进繁琐的实现细节。要从用户价值出发，先梳理出最外层的需求任务，然后抽丝剥茧，条分缕析地层层递 进，如此方能理清思路，掌控复杂逻辑。基本上，任务分解可以分为三个层次，即业务价值——>业务功能——>业务实现。并且这个层次是一种“递 归”的状态，视需求的复杂度而定。