收录了 tdd 频道下的 50 篇内容
最近酷壳的一篇有关TDD的文章引起了广泛关注,对于TDD一些人有自己不同的见解,为此InfoQ中文站特地邀请了InfoQ内外的敏捷专家特别是有丰富TDD实践经验的人,就TDD为InfoQ的读者分享他们自己的经验和体会。
实施TDD(测试驱动开发)实践的团队不再需要测试人员进行手工测试。对于测试人员来说,这种改变意味着他们以往所熟悉的工作内容逐渐消失了。同时,现代化的测试解决方案包含了更多技术性内容,因此需要专家的参与。对于测试人员来说,这是一个非常有吸引力的机会,但他们必须掌握扎实的技能。
测试驱动开发,它没想象中那么有价值。
最近,Dave Nicolette从Extreme Programming讨论组的一场讨论中提炼出来了一系列的TDD推荐教程。
TDD并不是一个开发者友好的开发模式,只是一个理想化的开发模式。
软件开发过程中,最惧怕的就是牵一发而动全身的修改,一个小小的修改有可能会引发蝴蝶效应,产生灾难性的问题,让很多开发工程师苦不堪言。本文介绍了TDD是如何改善这一问题的,它怎样帮我们节约了时间,带来了质量保障。
Mark Levison发现,在大型公司里,即使有了良好的课堂培训,团队采用TDD时仍然困难重重。为了更好地找出原因,他调查了团队的一些成员。在本文中,他分享了他所发现的问题,以及他自己对该问题的理解,目的是帮助大家在组织中更好地引入TDD。
TDD之路上荆棘密布,质疑者永在争论,而实践者披荆斩棘,持续前行。在这个过程中,作者不断探究新的实践“变种”,解决项目中遇到的一个个难题。
Agile和DevOps的成功的原因之一在于,开发人员改变他们的工作方式,采用了测试驱动开发(Test-Driven Development,TDD)。这种改变不会自然而然地发生,而大多数“常规”的推动改变的方法也并不适用于TDD。在本文中,作者将分享她在这方面的一些成功尝试,以及她在指导开发人员时所使用的“Samman”方法。
作为敏捷宣言的共同作者,我们熟知的鲍勃大叔Bob Martin,最近发表了一篇文章,对TDD是否会损害架构进行了评估。文中大部分讨论围绕着遵循测试驱动方法对高层设计和实现代码的总体可维护性是否会产生消极影响。
TDD不仅仅是一项技术,它还是一种完整的编程风格,一种相关行为和思想的综合系统。TDD的五个前提为我们提供了一个操作闭环,就像每个TDD实践者呼吸的空气一样。
Ruby on Rails的作者DHH最近发出“TDD已死”的言论,这在技术社区引起了轩澜大波,一些技术人员开始纷纷发表各自的看法表示支持或者反对。
本文汇总了一个大学教授放弃使用测试驱动开发(TDD)的经过以及鲍勃大叔对其论点的反驳。
在Empirical Software Engineering杂志上首次发表的一篇研究报告声称:“看来TDD可以应用在多个领域中,并显著降低软件的缺陷密度,同时也不会明显降低开发团队的工作效率。”研究对比了4个在微软和IBM执行的项目,这些项目使用了TDD方式开发,并与没有使用TDD开发的类似项目进行了对比。
加拿大工程学院的国家研究委员最近进行了一项关于测试驱动开发的研究。其他人对研究结果进行分析后,得到了一些有趣的结论,它涉及到测试先行方法相对于传统的后测试方法,能够在多大程度上、或者是否能够改善软件的质量。
2008年10月,Scott Ambler在Extreme Programming和Test-Driven Development两个邮件组内进行了有关TDD的调查,参与者共121人,调查结果已经在Scott Ambler的网站上发布。
在本文中,Mark Levison着重指出想采用TDD的开发者遇到了哪些困难,为什么许多尝试TDD的人很短时间内就放弃了,以及如何帮助开发者使采用TDD成为习惯。直接点击阅读完整文章。
在软件开发中,我们是应该奉理论原则为圣经,不越雷池一步,还是基于理论背后的思想,结合自己的实际问题,以实用主义的态度继续实践?让我们来看看作者在实际项目中采取的做法。直接点击阅读完整文章。
真正能让自己牺牲周末去做还能感到快乐和愉悦的事情是什么?
Peter Ritchie越来越担心TDD和BDD会导致它们的实践者无法写出好的单元测试。他认为,对“交互测试”的过度信赖(这是TDD和BDD最核心的内容)最终会导致不完整的单元测试。