鲍勃大爷:怎么做TDD编程?

19-12-15 banq

TDD:

在未通过测​​试的情况下,请勿编写任何生产代码。

一旦测试失败或编译失败,请停止编写该测试。

测试失败后,立即停止编写生产代码。

两者都重构,然后重复。

循环时间:〜10-60秒。

众说纷纭:

这显然很出色,但实际上,我所看到的更大的问题是,当您不愿使用TDD时,却面临着许多未经测试的传统意大利面条式代码。无数种依赖关系,乍一看,您看不到简单的出路

鲍勃大叔回复:规则1:不要让事情变得更糟。 (banq:如果人可以掌控一切,就可以不让事情变得更糟糕)

哈哈,仅运行测试可能需要60秒以上的时间。一个人可以考虑每次如何>测试10分钟以上...

回复:这源于对单元测试和集成测试之间差异的根本误解。单元测试仅在内存中运行,并且应该可以在几秒钟内执行。即使是数千次测试,也只需几秒钟即可运行。

我一直在做的事情,并推荐给任何人。一旦您开始这样做并习惯了它,生产力就会飞涨!

低于60秒的循环时间听起来不错,但它是本文中最不重要的部分。目标不是直接走得更快。TDD的间接好处是您最终会更快。任何人花更长的时间都没有做错。他们只是在想。思维好。

通常,需求是归结为软件开发中所有(大多数)成功和失败的根源。如果有明确定义的要求,那么以说明形式的TDD就是最好的编码方法。但有时我会做“探索性编码”,尝试在编码时想出自己想要的东西-TDD可能会占用我很多时间。(banq注:测试是代码的看门狗,但是需求是看门狗主人,软件最大难题是需求不断变化,而不是不变。)

TDD是不切实际且被高估的。我在编写代码时会考虑到测试,并在单元测试实际上会增加价值的地方添加测试代码。盲目地尝试达到100%的测试覆盖率通常只会导致维护许多无用的测试。

回复:100%的代码覆盖率不是TDD的目标。此外,遵循TDD与“盲目”执行操作完全相反。任何人对TDD的理解足够深刻,可以提出有效的批评。

在实践中,感觉自然地测试断言要比将测试断言特地写下来要自然得多:),在纯函数语言中,这是完全自然的,因为每种语言都可以立即进行测试,例如Haskell或LabVIEW。我还将测试人员变成使用API​​的示例。

 

                   

3
fateson
2019-12-20 11:23
who is 鲍勃大叔?

猜你喜欢