进食、睡眠和呼吸单元测试/TDD/BDD [已关闭]

2022-09-01 12:36:50

我在编写API和核心功能时编写单元测试。但我想成为一个很酷的粉丝,吃,睡,呼吸TDD和BDD。以正确的方式开始使用TDD/BDD的最佳方式是什么?任何书籍,资源,框架,最佳实践?

我的环境是带有Grails前端的Java后端,与几个外部Web服务和数据库集成。


答案 1

一个好的起点是阅读博客。然后购买正在写博客的人的书。我强烈推荐一些:

“鲍勃叔叔”马丁和Object Mentor:http://blog.objectmentor.com/

P.S. 获取 Bobs 书 Clean Code:

http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

我的朋友蒂姆·奥廷格(Tim Ottinger)(前对象导师)http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/

Jetbrains的家伙:http://www.jbrains.ca/permalink/285

我觉得有必要对此进行扩展,因为其他人似乎只想给你他们对TDD的看法,而不是帮助你成为绝地忍者。TDD的迈克尔·乔丹是肯特·贝克。他确实在上面写了这本书:

http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

他还在以下网址上发表博客:

http://www.threeriversinstitute.org/blog/?p=29

TDD的其他“著名”支持者包括:

所有人都是值得追随的好人。你还应该考虑参加一些会议,如敏捷2010或软件工艺(今年它们同时在芝加哥举行)


答案 2

我不喜欢人们说“练习X永远不会坏;如果它不起作用,你就没有做对。抱歉,它与任何其他过分热心的宗教教条具有相同的感觉。我不买。

我同意那些说你的时间和金钱所能负担得起的最佳解决方案应该是目标的人。

任何反对TDD的人都不应该自动被指控无视质量。(“那么你什么时候停止殴打你的妻子的?”事实是,软件中存在错误,消除所有这些错误的成本必须与收益进行权衡。

在制造业中也是如此。尺寸公差和表面光洁度并不完全相同,因为有时不需要紧密公差和镜面光洁度。

是的,我编写单元测试,尽管在我编写类之前并不常见。我已经看到了测试对设计的影响。我测量并观察代码覆盖率。如果我发现我的报道不可接受,我会写更多的测试。我了解单元测试安全网用于重构的好处。即使我独自工作时,我也会遵循这些做法,因为我亲身体验了这些好处。我明白了。

但是,我会对任何开始纠缠我“进食,睡觉,呼吸单元测试和TDD”的队友持怀疑态度。

我的经理说,能让我升职的唯一方法就是让团队进入TDD/BDD。

有没有想过,也许这让你听起来像一个烂摊子?你有没有发现你的唠叨已经疏远了团队的其他成员?

这种反应可能会让我失去一些声誉点,但不得不说。

我认为更好的方法是自己练习,让别人看到好处。以身作则。这比流口水更有说服力。

Geez,Grails内置了测试一代。如果你在一个使用Grails的团队中工作,还需要多少销售?


推荐