测试驱动的开发根本不涉及测试
如果您问我从肯特·贝克(Kent Beck)2003年的书中学到的关于测试驱动开发的最意外的事情是什么,那么我将确切地知道该怎么回答。 它也可能会让您感到惊讶,所以跳进去,让我们尝试从另一个角度看一下。 当您第一次听说TDD时,您如何看待它? 我记得这种感觉很好:这是“不,你不能认真对待,我该如何测试我什至还没有实现的东西?”的混合体,一种呆滞的感觉,“上帝,编写测试是太难了”和一点点耻辱,因为“优秀的程序员会执行自动化测试”,而我根本没有做太多的测试。 大概是十年前,那时我还在大学三年级,几乎没有任何“工业”经验。 TDD和其他敏捷思想正朝着阻塞软件开发流程的现代问题发展,这远非俄罗斯计算机科学专业的学生所理解。 TDD还对在实际项目中在地球上如何可行提出了疑问。 那你为什么决定读这本书? 几年后,我找到了我的第一份“工业”工作:那是一家俄罗斯大型互联网公司的测试软件工程师。 在很短的时间内,我看到了许多质量各异的代码,这些代码大多数时候都在巨大的负载下工作,并为公司带来了可观的收益。 我主要从外部探索代码,因为我最关心的是如何调用返回用户得分的服务,或者如何使数据处理守护程序以单进程模式启动,以便其行为至少在可预测期间可预测。测试。 但是我也偶然地窥视了内部。 我应该说这在大多数情况下是结构不良,难以理解的–塔达! -没有单元测试? 我对自己问的问题是,TDD似乎很有道理,为什么不将其应用于此处? 离开后,我去寻找答案-在书的页面上。 最后,最出乎意料的是什么?…