你真的在使用unit testing吗？
我参与了许多新旧项目，他们有一个共同点就是几乎没有一个人使用unit testing。 我更喜欢使用它，但是客户通常不会为此付费，而且假设代码正常工作。
那么，你在你的项目中使用unit testing，还是依靠你的编码技巧？
使用unit testing是一种编码技能。
我发现它给编码时间增加了很less的开销。 除此之外，所生成的代码往往更容易理解和重构，同时大大减less了维护时间。
对这里的好处进行充分的讨论： unit testing是值得的吗？
我会诚实的 我最近才开始编写unit testing，当我回到修改旧版本的旧DLL的时候，我会重新编写unit testing，让它接近100％的代码覆盖率。 我说“近”，因为最后的几个百分比很难得到，因为代码的结构，它没有嘲笑或unit testing（这发生了很多与抽象类或类P /调入本地代码）。 尽pipe我明白，100％的代码覆盖率与所有代码执行path的100％都不是一回事，但我发现在testing的时候有一个很好的方法可以告诉我什么时候做的事情会打破东西的。
说实话，这可能是导致许多开发人员（包括我自己）花了很长时间才能采用unit testing的原因之一（我们暂时还没有进入TDD）。
我并不是说这些都是正当的理由，但是他们多多lessless会经历我的头脑，我敢打赌，他们也经历了一些你的想法：
-
首先，有一个想法，大概是这样的：“哦，我已经写了一大堆代码，没有testing，看到我已经被这座山压死了，我没有时间再增加几个testing山代码在上面“。
-
其次，没有人喜欢谈论经典的代码运行 – debugging周期实际上“足够好”的事实
- 编写不会改变旧代码行为的新代码
- 在一个相对较小的软件项目或一次性工具上工作
- 一个项目的唯一开发者（你可以将大部分内容保留在你的脑海中）
-
第三，当你维护现有的代码时，unit testing更容易理解，而且如果你总是在编写新的代码，那么好处并不明显。 当你的工作是一个公用事业，而不再碰它时，开发人员在unit testing中看不到什么价值，因为他们可能不会在那个公用事业公司或公司工作，是一个unit testing）出现。
-
第四，unit testing是一个相当新的创新。 （哦，嘘……我知道这个想法一直存在，特别是在关键任务和国防部的应用程序，但像我这样的“
水pipe工开发人员”types？在我的整个CS期间没有提到unit testing在这个十年初期的大学生涯中; 2008年，我听说这是所有101级以上项目的要求，直到今年，Visual Studio甚至没有获得内置的testing框架，甚至只有在专业版）。对我而言，这是无知的无知吗？ 当然，我认为很多编码的人，因为这是他们的日常工作（这很好），根本不知道。 如果是的话，那么他们知道他们必须保持最新状态，但是在学习一种新的方法时（特别是需要编写更多的代码并在需要昨天完成新function时需要更多的预先准备时间的方法）意味着它会被推回去。 这是一个长尾巴，在十多年的时间里，我们关于unit testing的讨论看起来会像我们在20世纪90年代所做的关于面向对象编程的嘀咕一样让人耳目一新。 哎呀，如果我已经开始进行unit testing，那么最终的结果肯定是靠近的，因为我通常是一个白痴。 -
第五，unit testing的一些代码区域真的很难，这让我吓了一会儿。 想到multithreading事件队列，graphics渲染和GUI。 许多开发人员意识到这一点，认为“很好，unit testing对于图书馆代码来说是好的，但是什么时候是我最后一次只写一个类库”。 这需要一段时间。 为此，没有unit testing并不一定意味着错误的代码在前面。
-
最后，有时来自unit testing倡导者的传福音水平可能是令人生畏的和令人厌恶的。 说真的，我以为自己是个白痴，因为我无法理解如何嘲笑某个界面，为什么我想这样做。 自私地说，我想讨厌unit testing，因为每个人都不会闭嘴 。 没有银弹。
所以，为这个散漫的post道歉。 综上所述：
-
我没有很久的unit testing。 现在我做了。 unit testing是一个很好的工具，特别是在维护期间。
-
对于现有的项目，您至less可以进入并编写一个logging当前input和输出的testing。 将来如果你改变了一大堆黑暗的代码，你就可以看到你是否改变了这个小小的快照。 这也是改变贵公司发展文化的好方法。
让火焰开始燃烧吧！ =）
unit testing不能是事后考虑，它必须是一个因素，因为你的devise。 我甚至可以说，即使你从不写或者调用单个unit testing，它在领先的紧密元件驱动软件方面的好处在95％的时间里是值得的。
编写和运行unit testing是一个健康的编码过程的一部分，这不是一个额外的客户应该有select支付或不支付。
testing策略与其他任何testing策略一样是一个编码问题：使用什么数据结构，variables命名约定，注释标准等
在谈到几个正在生产但需要重大新function的项目之后，作为项目启动的技术领导者，我的一个底线是unit testing是必须的。
尝试重写没有进行unit testing的代码，花费太多。 代码总是很差的结构（一个数千行的Web服务，所有代码都在单个代码之后？），并且在没有引入错误的情况下对其进行修改（即使结构良好）也是一个非常痛苦的过程。
当一个项目进入消防模式时（尤其是没有unit testing有助于项目进入该状态），情况变得尤其如此 – 客户变得脾气暴躁，他们对项目失去信心，没有什么事情比成为穷人试图得到下一个修复，而不会引入一大堆的回归错误，甚至没有unit testing。
这些情况可以很容易地避免，或者至less通过预先解释testing的价值来减轻。 当然，unit testing并不是那么重要，但确实是个例外。
所以是的 – 我坚持unit testing，花了很多时间来修复其他开发人员依赖编码技能所造成的混乱。
我可以随时使用unit testing和tdd。 然而，根据我对每个unit testing提倡者的经验，有三个或更多的开发人员并不真正相信编写unit testing是值得的，而且会减慢开发速度。 然而这些人往往保持安静，所以你不可能在这里看到很多。
我喜欢鲍勃·马丁的比喻：假设你是外科医生。 你想给一个想要付钱的病人说什么，但是提醒你不要提前洗钱？
当客户聘用我来编码时，他们雇用我作为一个专业人员，作为一个有专业技能和纪律的人。 我的工作就是给他们“代码正常工作”， 我知道使用TDD的最好方法是使用TDD。
我是unit testing的忠实粉丝，主要是因为它是完全容易上瘾的 – 在JUnit中的“代码testing – 看到可怕的红色条形修复testing – 看见可爱的绿色酒吧”循环严重地获得了内啡肽泵送。
我同意Ken的观点，unit testing是软件开发的一部分。
关于成本问题，比编写代码还要多，unit testing比编写代码要长。 但是，当您将代码与其testing（称为TDD – testing驱动开发）一起编写时，将以“ 干净的代码有效 ”结束。 当你只是写代码，那么你必须使它的工作，这可能是漫长而痛苦的。
另一个好处是，你知道你在哪里，因为已经编写的代码已经过unit testing。
要回答你的问题，是的，我可以在项目中使用unit testing。 我为所有新代码编写unit testing，并努力寻找遗留代码。
我经常对复杂的mathalgorithm使用unit testing，例如LineIntersectsLine等函数，您可以在其中定义一些要testing的重要示例。 之后，更容易控制这个function。 您可以简单地重写/优化它，并testing它是否仍然有效，或者如果遇到错误，可以添加新的testing，然后尝试更正这些错误。
我发现新的开发人员从unit testing中受益更多，而不是那些不得不向学校学习可能导致失败的陷阱的学校。 unit testing不会带来好的devise – 只会导致devise更具可测性。 你需要testing你的代码，但unit testing的方式是危险的。 “这会迫使你更好地devise你的代码”，“你怎么testing它是否正确？”。
我更喜欢写好结构化的代码，当你阅读它时会自动告诉你它正在试图完成什么以及如何完成它。 函数/类应该小而简洁。 他们应该只有一个责任。 unit testing不能防止逻辑错误。
unit testing给出了比其他任何东西更多的误报，尤其是当项目第一次写入时。 好的devise胜过testing – testing应该只是validation阶段。 我从来没有买入到testing之前的所有其他概念。 以我的经验来看，这种思路倾向于以可扩展代码为代价的可testing性（对于一次性项目或者一次性实用程序可能是可以的，但具有讽刺意味的是，unit testing对于这些代码并不重要）。
我公司为航天工业的各个公司制造系统组件。 FAA要求质量等级A安全关键飞行软件（ DO-178-B ）的修改条件/决策覆盖范围因此为了validation我们（同样来自DO-178-B）：
通常需要分析从testing和结果到所有需求的所有代码和可追溯性（取决于软件级别）。
这个过程通常还涉及：
基于需求的testing工具
代码覆盖率分析工具
在这个过程中执行的testing的其他名称可以是：
unit testing
集成testing
黑匣子和验收testing
unit testing总是显示代码错误。
我从经验中知道，当我在没有unit testing的情况下编写代码时，会遇到一些问题需要解决，但是当我编写unit testing时，我很less听到有关问题。 另外，从写unit testing的时间开始，我写了更好的代码。 我研究方法，思考他们可能会失败的方式，从一开始就build立起来，不至于失败，或者至less是以更好的方式失败。
unit testing对于编写更好的代码是必不可less的，但是它也会使你成为一个更好的开发者，因为你看到的地方可能会出错，并在你进行testing之前修复它们。
unit testing是开发的重要组成部分，而且（我发现）实际上会减less完成项目的时间，同时提高整体质量，特别是在TDD时代完成时。
我做unit testing。 我现在正在制定一个约束validation引擎，我的客户希望它是防弹的。 那么，没有unit testing，我会死于压力…
所以是的，我用它！
我写的大部分函数都有testing。 像许多人曾经说过的那样，unit testing是软件工程的重要组成部分。 所以，要回答你的问题，是的，我真的写和运行testing。
此外，通过持续集成 ，回归testing将自动化并不断报告。
关于依靠我的编码技能，我发现当我使用TDD时，我的编码技能实际上有所提高，并且在我testing时依靠我的unit testing来纠正我。 您将学习如何使用许多语言function，因为您可以进行微调以testing一个假设。
另一个非常有用的提醒，你为什么要进行unit testing，只要你在这个post中出现： 编写unit testing的12个理由我需要把它刻在我的视网膜上。
我可以亲自作证，思考如何从一开始就testing什么，并通过每次迭代开发testing。 我需要更系统一些，我自己。 我现在打印出这个清单。
如果进行unit testing，您的客户可能会整体省钱。 如果在开发阶段稍后发现，而不是在unit testing期间发现，unit testing阻止的部分错误则更为重要。 它在未来会节省很多的头痛，现在我使用它，我不认为我会回头。
