wby*_*ung 21
以下是TDD可能对开发人员/团队有所帮助的三个原因:
首先编写测试的一个原因是在编写之前更好地理解实际代码.对我而言,这是测试驱动开发的主要好处.当您首先编写测试用例时,您会更加批判性地考虑角落情况.在编写代码并确保它们准确时,更容易解决它们.
另一个原因是实际执行编写测试.通常当人们在没有TDD的情况下进行单元测试时,他们会设置测试框架,编写一些新代码,然后退出.他们认为代码已经运行得很好,为什么要编写测试呢？这很简单,它不会破坏,对吗？但是现在你已经失去了首先进行单元测试的优势(完全不同的讨论).先写下它们,它们已经存在了.
首先编写这些测试可能意味着您不需要在调试环境中启动该程序(特别是对于较大的项目而言),以测试是否有一些小的工作.当然,在进行更改之前没有理由不这样做.
说服自己或其他人先写测试可能很困难.你可能有更好的运气让他们同时写两篇文章,这可能同样有益.
大概是你在将它提交到存储库之前测试了你编写的代码.
如果那不是真的,你还有其他问题要处理.
如果是这样,您可以使用框架来编写测试,以便自动化当前编写的主要例程或驱动程序,这样您只需按一下按钮就可以自动运行所有这些例程或驱动程序.您不必仔细考虑输出以确定测试是通过还是失败; 您将测试的成功或失败嵌入到代码中,并立即做出竖起或下降的决定.一次运行所有测试可以减少"敲打鼹鼠"的可能性,在这种情况下,您可以在一个类中修复某些内容并破坏其他内容.所有的测试都必须通过.
听起来不错,是吗？
TDD人员要求你在写完课程之前先写下测试FIRST,然后再向前迈进一步.当然,它失败了,因为你没有写过这门课.这是他们保证你编写测试类的方法.
如果您已经在使用测试框架,从您编写的测试中获得良好的价值,并且有意义的代码覆盖率达到70%左右,那么我认为您做得很好.我不确定TDD会给你更多的价值.由你来决定你是否加倍努力.就个人而言,我不这样做.如果我认为有需要,我会在课后编写测试并重构.有些人可能会发现在首先知道它会失败的情况下编写测试会有所帮助,但事实并非如此.
(这更像是一个评论,同意duffymo的答案,而不是自己的答案.)
duffymo答案:
TDD人员要求你在写完课程之前先写下测试FIRST,然后再向前迈进一步.当然,它失败了,因为你没有写过这门课.这是他们保证你编写测试类的方法.
我认为这实际上是迫使程序员考虑他们的代码在做什么.必须考虑测试才能考虑代码应该做什么:前置条件和后置条件是什么,哪些函数是原始的,哪些是由原始函数组成的,最小的必要公共接口是什么,以及什么是一个实现细节.
这些都是我经常考虑的事情,所以像你一样,"先测试" 对我来说并没有增加太多.坦率地说(我知道这在某些圈子里是异端)我喜欢先勾勒出公共界面,然后"锚定"一个类的核心思想; 通过这种方式,我可以看一下,精神上使用它,看看它是否像我想象的那样干净.(类或库应该简单直观,供客户端程序员使用.)
换句话说,我做的是TDD尝试通过首先编写测试来确保发生,但是像duffymo一样,我以不同的方式实现目标.
而"先测试"的真正意义在于让编码人员像设计师一样停下来思考.嘲笑程序员如何进入该状态是愚蠢的; 对于那些不自然地做到这一点的人来说,"先测试"可以作为让他们到达那里的仪式.对于那些做过的人来说,"先测试"并没有增加太多 - 并且可能妨碍程序员习惯性地进入该状态.
同样,我们想要看结果,而不是仪式.如果一个初级人需要一个仪式,一个"十字架"或一个念珠*来"陷入困境","先测试"就是为了这个目的.如果有人有自己的方式也到那里,那也很棒.
请注意,我并不是说不应该测试代码.这应该.它为我们提供了一个安全网,这反过来又使我们能够集中精力编写好的代码,甚至是大胆的代码,因为我们知道网络可以捕获错误.
我所说的是,对"先测试"的拜物教坚持将这种方法(许多方法之一)与目标混为一谈,使程序员思考他正在编码的内容.
*为了普及,我会注意到天主教徒和穆斯林都使用念珠.而且,这是一种机械的,肌肉记忆的方式,使自己进入某种心境.这是一种迷信(在原始意义上的魔法物体,而不是"性迷信"的含义)或者好运的魅力.所以说"Om mani padme hum",或者坐着zazen,或者抚摸着一只"幸运的"兔子的脚(对兔子来说不是那么幸运.)哲学家Jerry Fodor在考虑难题时也有类似的仪式:他重复一遍对自己说,"来吧,杰里,你能做到!" (我也试过了,但因为我的名字不是杰瑞,所以它对我不起作用.;))
| 归档时间： |
|
| 查看次数： |
11461 次 |
| 最近记录： |