你真的在使用单元测试吗？

我参与了许多新老项目,他们有一个共同点,那就是他们几乎都没有使用过单元测试.我更喜欢使用它,但通常客户不愿意为此付费,并假设代码正常工作.

那么,您是否在项目中使用单元测试,还是依靠编码技能？

使用单元测试是一种编码技巧.

我发现它为编码时间增加了很少的开销.最重要的是,生成的代码往往更容易理解和重构,并且维护时间大大减少.

这里的好处有一个完整的讨论:单元测试值得努力吗？

我会说实话.我最近才开始编写单元测试,当我回去修改一个旧的DLL,这是我过去的糟糕时期,我会蹲下来编写单元测试,使其接近100%的代码覆盖率.我说"接近"因为最后几个百分点很难达到,因为代码的结构方式,它没有考虑模拟或单元测试(这种情况在抽象类或类中发生了很多P /调用本机代码).虽然我知道100%的代码覆盖率与100%的所有代码执行路径不同,但我发现在那里进行测试有一个好方法可以告诉我什么时候我会做很多事情会破坏很多东西的.

说实话,这可能是为什么它让很多开发人员(包括我自己)花了很长时间来采用单元测试(让我们暂时不进入TDD)的原因之一.

我并不是说这些都是合理的原因,但是他们或多或少地做了我的头脑,我敢打赌他们也经历过你们的一些人:

首先,有一个想法是"哦,我已经编写了大量的代码,零测试,看到我已经被那座山压碎,我可能没有时间再添加几个测试山代码就在它之上."

其次,没有人喜欢谈论这样一个事实:经典的代码运行调试循环实际上在你工作时"足够好"

编写不会改变旧代码行为的新代码

在一个相对较小的软件项目或一次性实用程序上工作

项目的唯一开发人员(你可以将其中的大部分保留在头脑中,直到某一点)

第三,当您维护现有代码时,单元测试更容易理解,如果您总是编写新代码,那么好处并不是很明显.当你的工作是制作一个实用程序并且再也不会再触摸它时,开发人员在单元测试中看不到什么价值,因为他们可能不会在维护程序员(希望那里工作)时在该实用程序或公司上工作是一个单元测试)来了.

第四,单元测试是一项相当新的创新.(哦,嘘......我知道这个想法永远存在,特别是在关键任务和DoD应用程序中,但对于" 管道工的乔"开发人员"像我这样的类型？在本十年初的整个CS本科生涯期间都没有提到单元测试;在2008年,我听说这是101级以上所有项目的要求.Visual Studio甚至没有得到一个内置的测试框架,直到今年,甚至只有专业版.)我的幸福无知吗？当然,我认为很多人编码,因为这是他们的日常工作(这很好)根本不知道.如果他们是,那么他们知道他们必须保持最新状态,但是当谈到学习一种新方法时(特别是涉及编写更多代码并在需要新功能时需要更多预先准备时间的方法)昨天完成了)意味着它会被推回去.这是一个长尾巴,在十年左右的时间里,我们关于单元测试的讨论看起来就像我们对面向对象编程的嘀咕一样古怪,这种编程能够在20世纪90年代实现新的发展时代.哎呀,如果我开始进行单元测试,最终必须靠近,因为我通常是个白痴.

第五,单元测试某些代码区域真的很难,这让我害怕了一段时间.我想到了多线程事件队列,图形渲染和GUI.许多开发人员意识到这一点,并认为"好吧,单元测试对于库代码来说会很棒,但是最后一次我只写了一个类库." 需要一段时间才能到来.为此,没有单元测试并不一定意味着未来的代码不好.

最后,有时来自单位测试倡导者的传福音水平可能是令人生畏和令人反感的.说真的,我以为我是个白痴,因为我无法掌握如何模拟某个界面以及我为什么要这样做.自私地,我想讨厌单元测试,只是因为每个人都不会关闭它.没有银弹.

所以,为漫无边际的帖子道歉.综上所述:

我很长时间没有进行单元测试.现在我做.单元测试是一个很好的工具,特别是在维护期间.

对于现有项目,您至少可以进入并编写一个记录当前输入及其输出的测试.当你将来改变那些大杂乱的代码时,你将能够看到你是否改变了那个小快照.这也是改变贵公司发展文化的绝佳方式.

让火焰开始燃烧吧!=)

单元测试不能成为事后的想法,它必须是影响您设计的因素.我甚至会说,即使你从不编写或调用单个单元测试,它在引导紧密组件驱动的软件方面的优势在95%的时间内都是值得的.

我喜欢Bob Martin的比喻:想象你是一名外科医生.对于想要支付手术但又告诉您提前跳过洗手的患者,您会怎么说？

当一个客户雇用我代码时,他们雇用我作为专业人士,作为具有专业技能和纪律的人.我的工作是给他们"代码正常工作",我知道我这样做的最好方法是使用TDD.

在进入一些正在生产但需要主要新功能的项目之后,我作为技术主管启动项目的一个底线是单元测试是必须的.

尝试重写没有单元测试编写的代码只需花费太多成本.代码总是结构不合理(一个数千行的Web服务都在一个代码后面的任何人身上？)并且在不引入错误的情况下对其进行更改(即使它结构良好)也是一个非常痛苦的过程.

当一个项目进入灭火模式时(尤其是没有单元测试有助于项目进入该状态),这一点尤其如此 - 客户变得脾气暴躁,他们对项目失去了信心,没有比做穷人更糟糕的事情了.尝试在不引入一大堆回归错误的情况下获得下一个修复,甚至没有进行单元测试.

通过预先解释测试的价值,可以很容易地避免或至少减轻这些情况.当然,有些情况下单元测试不是那么重要,但它们确实是例外.

所以是的 - 我坚持进行单元测试,并花了很多时间来修复依赖于编码技能的其他开发人员制造的混乱.

编写和运行单元测试是健康编码过程的一部分,它不是客户应该选择支付或不支付的额外费用.

测试策略与任何其他问题一样是一个编码问题:使用什么数据结构,变量命名约定,注释标准等.

我尽可能使用单元测试和tdd.然而,根据我对每个单元测试倡导者的经验,有三个或更多开发人员并不真正相信编写单元测试是值得的,并且它会减慢开发速度.然而,这些人往往保持沉默,所以你不太可能在这里看到很多.