TDD 已死,测试万岁!
作者:网络转载 发布时间:[ 2015/10/12 13:41:55 ] 推荐标签:测试驱动开发 行为驱动开发
所以接下来我们该何去何从呢? (So where do we go from here?)
第一步是承认问题。我认为现在我们已经做到了这一步。第二步是重新平衡从单元测试到系统测试间的频谱 (spectrum)。目前狂热的 TDD 的经验导致了在测试上都聚焦于单元测试,因为这是可以驱动代码设计的测试(这也是初社群鼓吹测试先行的初理由)。
我不认为这是健康的。先写单元测试导致我们产生了一堆复杂的中介物件作和间接层,以避免让单元测试太「慢」。像数据库存取、档案 I/O、或是通过浏览器来测试系统,都会被隔离出来(译注?一般建议每个单元测试的执行时间不能超过 500ms,另外不建议单元测试和外部资源 - 象是 DB、档案系统 - 相依。为了达成这目标,我们常会将待测物件 A 的相依物件 B、C、D 以界面隔离,在单元测试时,使用像 Mock/Stub 的方式来注入假造的物件 B、C、D 给物件 A。一方面让物件 A 不会存取外部资源,另一方面也让整个单元测试够快)。这种方式带来了一个真正可怕的怪物架构?一堆复杂的服务物件、命令模式或其他更糟的东西。
我很少撰写在传统意义上的单元测试?假造所有的相依物件,来让上千个测试可以在几秒内测试完毕。因为它对于测试 Rails 应用程序并不是一个有用的方法,我会直接测试 active record model,让它们透过 fixture 来存取数据库。然后以这为基础,在上层运行一组对于 controller 的单元测试,但对我来说,我更愿意使用像 Capybara 或类似的系统测试工具,来取代这些单元测试。
我认为这是我们应该前进的方向?减少对于单元测试的重视。因为我们不再做测试先行的设计实践,而是更加重视 - 喔,是的 - 执行速度更慢的系统测试。(顺便补充一下,由于平行化和云端基础建设的成熟,系统测试其实也不会比单元测试慢得这么多)
Rails 可以帮助大家做这种转移。我们不鼓励完整的系统测试,在开发的堆栈中也没有预设的答案,这是一个我们将要修复的错误,但您不必等到这件事发生,让 Capybar 从介入您的开发周期,如此一来您将会有我们正朝着美好明天的正面思维。
但首先,让我们先深呼吸一下。我们正在驱赶一些神圣的奶牛进屠宰场,这是痛苦和血腥的过程。TDD 是如此成功,以至于它结合了许多程序设计师。TDD 所代表的是不只是它在开发方法上的技法,还有背后以此技法开发的从业人员。(TDD is not just what they do, it's who they are.) 我们必须消除在我们面前巨大社群的思考惯性,而这将需要一些时间。
我们能做的糟糕的事情是再跳到另一个关于测试的宗教,我可以想象那个新宗教的标语是「只做系统测试! 」。请不要再度跳到那个坑去。
是的,测试优先对我来说已经死了。但比起在它的坟墓上跳舞,我更想做的是向它的贡献表达我的敬意。它在我们的(开发方法论)历史上占有一个重要的阶段,但现在是时候让我们继续前行了。
测试万岁!(Long live testing.)
本文内容不用于商业目的,如涉及知识产权问题,请权利人联系SPASVO小编(021-61079698-8054),我们将立即处理,马上删除。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11热门文章
常见的移动App Bug??崩溃的测试用例设计如何用Jmeter做压力测试QC使用说明APP压力测试入门教程移动app测试中的主要问题jenkins+testng+ant+webdriver持续集成测试使用JMeter进行HTTP负载测试Selenium 2.0 WebDriver 使用指南