如果只是研发出了产品功能，但是对其测试不充分，这个功能就附着了测试债务，并且随着时间推移，测试债务会越隐藏越深，偿还成本会越来越高。
同理，如果只是研发出了产品，但是代码结构不健壮（比如：代码逻辑繁杂不精简高效、跨模块耦合过高），这个产品也就附着了开发债务，随着产品架构的发展，开发债务越来越高，摇摇欲坠的代码如屎山一般，每次产品的进一步发展你都会被恶心一次。这个问题曾经进行过思考，在🔗《互联网产品研发效率，这篇说的够明白了！》中讨论了技术架构和产品架构的双螺旋发展关系。
面对测试债务，测试驱动研发(Test-DrivenDevelopment,TDD)是一种新的思路以预防这种情况的发生。TDD是一种敏捷开发思想，既然所有的功能点都需要测试，而且是反复测试，为什么不把测试工作提到最前面并自动化呢?
TDD要求在写任何功能代码之前，先写好它的测试代码，以保证所有的功能点都被自动化测试所覆盖。从而规避了【产品-->开发-->测试】这种低效的线性路径以及大概率会出现的信息传输漏斗，导致功能到代码到测试的不断衰减，最终交付质量堪忧、未来again时的巨大难题。
TDD正是从一开始就解决测试债务的方法，当产品变得很庞大的时候，TDD依然可以快速有效地检测各个功能点，这对于没有运用TDD的产品来说是一项不可能完成的任务。从研发驱动测试到测试驱动研发，是一个巨大的转变，其中涉及研发流程、测试人员的编程能力、研发平台对自动化测试的支持程度等环节。
不过，在测试驱动研发出现之前，那么多研发驱动测试的产品也获得了成功，所有这些因素都影响了TDD的普及。
话说至此，TDD测试驱动研发中的“Driven”一词值得思量，逻辑关系上测试始终是为研发服务，而非代码为测试而生。与其说是测试“驱动”研发，不如说测试“可视化”研发、测试“螺旋化”研发，那么可视化/螺旋化在于什么呢？
研发服务于产品功能，产品功能服务于业务/用户需求，测试服务于研发并有助于研发。测试为纲，更是一种思想，使得研发过程时刻考虑到代码逻辑的可视化、可测试化、可自动化复测，从而促进提升代码质量、可检测性、可持续性。测试代码的领先搭建，有一个现实的例子可以对比。
1️⃣一栋大楼，是一个产品——满足于市场（商业、住宅）需求
2️⃣建筑设计图纸（土建/结构/装修）——可以算是产品设计方案
3️⃣建筑主体、装修装饰——对应代码主体的后端和前端
4️⃣施工自检/监理监察/三方质检——算是测试
在建筑施工管理过程中，本位上来看监理是在施工工序之后进行的，但实际上监理的大纲方案、监理细则，其实在产品设计方案出来之后，就已经在展开了。同样的，施工（研发）过程也会根据监理的监察原则，在指定的关键点做好检验预留。
由此也看出来二者并非严格的先后关系，更像是一种螺旋缠绕关系，监理/测试为纲、为镜，对施工/研发进行约束和检验，这是一种典型的共建、共生。
如果你的产品总是出现无法定位的奇怪问题，那么应该要考虑一下转用TDD了，当然，最终的决策权在测试经理或研发经理，更重要的是需要团队成员接受这种思想并在项目中进行践行。
网友评论