unit testing是值得的吗？
我正在将unit testing整合到我所从事的团队的开发过程中，并且有一些怀疑者。 有什么好的方法来说服团队中怀疑开发者团队testing的价值？ 在我的具体情况下，我们将添加unit testing，因为我们添加function或修复错误。 不幸的是，我们的代码库不适合简单的testing。
我们办公室的每一天都有一种交stream，就像这样：
“男人，我只是喜欢unit testing，我只是能够对事情的方式进行一系列的改变，然后通过再次运行testing来证实我没有破坏任何东西……”
细节每天都在改变，但情绪不变。 unit testing和testing驱动开发（TDD）有许多隐藏的和个人的好处，以及明显的隐藏的和个人的好处，除非他们自己做，否则你无法真正向人解释。
但是，忽略这一点，这是我的尝试！
-
unit testing允许您快速地对代码进行大的更改。 你知道它现在可以工作，因为你已经运行了testing，当你做出需要做的改变时，你需要重新开始testing。 这节省了数小时。
-
TDD帮助您了解何时停止编码。 你的testing让你相信自己现在已经做得足够了，可以停止调整，继续下一步。
-
testing和代码一起工作以获得更好的代码。 你的代码可能是坏/马车。 你的testing可能是坏/马车。 在TDD中，您正在为糟糕/越野车低的机会提供服务。 通常这是需要修复的testing，但这仍然是一个好的结果。
-
TDD有助于编码便秘。 当面临大量艰巨的工作时，testing会让你快速行动。
-
unit testing可以帮助你真正理解你正在使用的代码的devise。 不是编写代码来做某件事，而是首先概述代码的所有条件以及你期望得到的结果。
-
unit testing给你即时的视觉反馈，当我们完成时，我们都喜欢所有那些绿灯的感觉。 这非常令人满意。 在中断之后从中断的地方也很容易，因为你可以看到你需要的位置 – 下一个需要修复的红灯。
-
与stream行的观点相反，unit testing并不意味着编写两倍的代码，或者编码速度较慢。 一旦你掌握了它，它比没有testing的编码更快更强大。 testing代码本身通常是相当平凡的，不会给你所做的工作增加很大的开销。 这是你只会相信，当你这样做:)
-
我认为这是福勒说的：“不完美的testing，经常运行，比完全没有被写入的完美testing要好得多”。 我将这解释为允许我编写testing，即使我的代码覆盖率的其余部分是严重不完整的，我认为它们将是最有用的。
-
良好的unit testing可以帮助文档和定义什么是应该做的
-
unit testing有助于代码重用。 将您的代码和testing迁移到您的新项目。 调整代码，直到testing再次运行。
我参与的很多工作都没有unit testing（Web应用程序用户交互等），但即使如此，我们都在这家商店受到感染，而且当我们的testing受到束缚时，我们感到最开心。 我不能高度推荐这种方法。
unit testing很像去健身房。 你知道这对你有好处，所有的论据都有道理，所以你开始锻炼。 有一个最初的热潮，这是伟大的，但几天后，你开始怀疑是否值得麻烦。 你要花一个小时去改变你的衣服，在仓鼠轮子上跑，你不知道除了疼痛的腿和arm之外，你真的得到了什么。
然后，在一两周之后，就像疼痛消失一样，一个大截止date即将开始。 你需要花费每一个清醒的时间去完成“有用的”工作，所以你要去掉那些无关的东西，比如去健身房。 你没有这个习惯，大截止时间结束的时候，你又回到原点了。 如果你设法让它回到健身房，你感觉就像你第一次去的时候那么疼。
你做一些阅读，看看你是否做错了什么。 你开始感到一点点不合理，尽pipe所有的合适，愉快的人颂扬运动的美德。 你意识到你没有太多的共同点。 他们不必开车15分钟就可以去健身房; 有一个在他们的build筑物。 他们不必与任何人讨论锻炼的好处; 这只是每个人都做的事情，而且也是重要的。 当一个大截止date接近时，他们不会被告知，锻炼是不必要的，比你的老板要求你停止进食更有必要。
所以，为了回答你的问题，unit testing通常是值得的，但是所需的努力量对于每个人来说都不一样。 如果你正在处理一个实际上并不重视代码质量的公司的意大利面条代码库，unit testing可能需要付出巨大的努力。 （很多经理会唱“unit testing”的称赞，但这并不意味着在重要的时候会坚持下去。）
如果你试图将unit testing引入你的工作，并没有看到你所期望的所有阳光和彩虹，不要责怪自己。 你可能需要找一份新的工作来真正使unit testing为你工作。
最好的方式说服…find一个错误，写一个unit testing，修复错误。
这个特殊的bug不太可能再次出现，你可以用你的testing来certificate它。
如果你这样做，其他人会很快赶上。
thetalkingwalnut问：
有什么好的方法来说服团队中怀疑的开发者团队testing的价值？
为什么unit testing是好的，那么这里的每个人都会出于各种理由而深思熟虑。 然而，我发现说服某人某事的最佳方法是倾听他们的论点，并逐一解决。 如果你倾听并帮助他们expression他们的担忧，你可以解决每个问题，也许把他们转换成你的观点（或者至less让他们不用站立）。 谁知道？ 也许他们会说服你为什么unit testing不适合你的情况。 不太可能，但可能。 也许如果你发表反对unit testing的论点，我们可以帮助确定反驳。
倾听和理解论证的双方是很重要的。 如果你试图过于热情地采用unit testing，而不考虑人们的担忧，那么你最终会发生一场宗教战争（也许真的是毫无价值的unit testing）。 如果你慢慢采用它并开始应用，那么你将能够以最小的代价看到最大的收益，那么你可能能够certificateunit testing的价值，并且有更好的说服人的可能性。 我意识到这并不像听起来那么容易 – 通常需要一些时间和细致的指标来制定一个有说服力的论点。
unit testing是一个工具，就像其他任何工具一样，应该以这样一种方式来应用，即好处（捕捉错误）超过成本（编写它们的努力）。 不要在他们没有意义的地方使用它们，记住它们只是工具库中的一部分（例如检查，断言，代码分析器，forms化方法等等）。 我告诉我的开发者是这样的：
-
如果他们有一个好的论点，那么他们可以跳过写一个方法的testing，为什么它是没有必要的（例如太简单，不值得或者太难以值得），以及如何validation方法（例如检查，断言，forms方法，交互/整合testing）。 他们需要考虑一些validation，如检查和formscertificate是在某个时间点完成的，然后每当生产代码改变时需要重复validation，而unit testing和断言可以用作回归testing（一次写入，然后重复执行）。 有时候我同意他们，但是更多的时候我会争论一个方法对unit testing来说太简单还是太难。
-
如果一个开发者认为一个方法看起来太简单而不能失败，那么写出一个简单的5行unit testing是否值得60秒？ 这五行代码每晚都会运行（你每天晚上做的，对不对？），如果碰到可能需要15分钟或更长时间才能识别的问题和debugging。 另外，编写简单的unit testing会增加unit testing的次数，这使开发人员看起来很好。
-
另一方面，如果一个开发者认为一个方法似乎太难以进行unit testing（不值得花费大量的精力），那么这个方法可能是一个很好的指示，这个方法需要被分解或重构来testing简单的部分。 通常情况下，这些方法依赖于不寻常的资源，例如单例，当前时间或像数据库结果集这样的外部资源。 这些方法通常需要被重构为获取资源的方法（例如调用getTime（））以及将资源作为参数的方法（例如，将时间戳作为参数）。 我让他们跳过testing检索资源的方法，而是为现在将资源作为参数的方法编写一个unit testing。 通常，这使得编写unit testing更简单，因此值得编写。
-
-
开发者需要在他们的unit testing应该是多么全面绘制一条“沙子线”。 在开发的后期，每当发现错误时，应该确定是否有更全面的unit testing能够解决问题。 如果是这样，并且如果这样的错误反复出现，他们需要将“线”移到将来编写更全面的unit testing（从添加或扩展当前错误的unit testing开始）。 他们需要find适当的平衡。
实现unit testing的重要性不是银弹，unit testing太多了。 在我的工作场所，每当我们吸取教训，我不可避免地听到“我们需要写更多的unit testing”。 pipe理层点头表示同意，因为它已经被“unit testing”==“好”了。
但是，我们需要了解“更多unit testing”的影响。 一个开发者一个星期只能写出〜N行代码，你需要弄清楚代码的百分比应该是unit testing代码还是生产代码。 松散的工作场所可能有10％的代码作为unit testing，90％的代码作为生产代码，导致产品有很多（尽pipe非常麻烦）function（想想MS Word）。 另一方面，90％的unit testing和10％的产品代码的严格的商店将具有很less的function（如“vi”）的坚如磐石的产品。 您可能永远听不到有关后者产品崩溃的报道，但是这可能与产品销售不如销售得好像代码质量一样。
更糟糕的是，也许软件开发的唯一确定就是“变化是不可避免的”。 假设严格的商店（90％的单位testing/ 10％的生产代码）创造了具有2个特征的产品（假设产品代码== 1特征的5％）。 如果客户出现并更改了其中一项function，则该更改会占用50％的代码（45％的unit testing和5％的生产代码）。 宽松的店铺（10％的unit testing/ 90％的生产代码）有一个产品有18个function，没有一个工作得很好。 他们的客户完全改造了他们的四个特点的要求。 尽pipe这个变化是4倍，但只有一半的代码被丢弃（〜25％=〜4.4％的unit testing+ 20％的生产代码）。
我的观点是，你必须告诉你，你明白在unit testing过less和过多之间的平衡 – 基本上你已经考虑了这个问题的两个方面。 如果你能说服你的同事和/或你的pipe理层，你会获得信誉，也许有更好的机会赢得他们。
我曾经玩过多次unit testing，但我仍然相信，根据我的情况，这是值得的。
我开发的网站，其中的大部分逻辑涉及创build，检索或更新数据库中的数据。 当我为了unit testing目的而试图“模拟”数据库时，它已经非常混乱，似乎有点没有意义。
当我编写关于业务逻辑的unit testing时，从未真正帮助过我。 因为我主要在项目上工作，所以我倾向于直观地知道哪些代码区域可能会受到我正在处理的某些内容的影响，并且我会手动testing这些区域。 我想尽快为客户提供解决scheme，而unit testing往往是浪费时间。 我列出手动testing，并自己走过，在我走的时候把它们打勾。
我可以看到，当一个开发团队正在开发一个项目并更新对方的代码时，这可能是有益的，但即使如此，我认为如果开发人员是高质量的，那么良好的沟通和良好的代码应该足够。
关于unit testing的一个好处是，它们可以作为你的代码的行为文档。 好的testing就像一个参考实现，队友们可以看看他们，看看如何把你的代码和你的代码结合起来。
unit testing是非常值得的初始投资。 自从几年前开始使用unit testing以来，我发现了一些真正的好处：
- 回归testing消除了对代码进行更改的担心（没有什么比看到代码工作的热情焕发或者每次发生更改都会发生爆炸）
- 其他团队成员的可执行代码示例 （和你自己在六个月的时间..）
- 无情的重构 – 这是令人难以置信的奖励，试试吧！
代码片段可以大大减less创buildtesting的开销。 创build片段使得在几秒钟内创build类别轮廓和相关的unit testing夹具并不困难。
你应该尽可能less的testing！
意思是，你应该写足够的unit testing来揭示意图。 这经常被掩盖。 unit testing花费你。 如果你做了改变，你必须改变testing，你将不太敏捷。 保持unit testing简短而甜蜜。 然后他们有很多的价值。
我经常看到很多testing永远不会破，大而笨拙，不能提供很多价值，最终会让你放慢速度。
我没有看到任何其他答案，但有一点我注意到， 我可以更快地debugging 。 您不需要通过正确的步骤顺序来深入了解您的应用程序，以便find您的修复代码，只是发现您已经做出布尔错误，并且需要再次完成这一切。 通过unit testing，您可以直接进入您正在debugging的代码。
[我有一点让我不能看到上面]
“每个人unit testing，他们不一定意识到 – 事实”
想想看，你写了一个函数来parsing一个string并删除新的行字符。 作为一个新手开发者，你可以通过在Main（）中实现它来从命令行运行一些例子，或者你可以用一个button来组合一个可视化的前端，把你的函数绑定到几个文本框和一个button，怎么了。
这是unit testing – 基本和糟糕的放在一起，但你testing一些情况下的代码段。
你写一些更复杂的东西。 当你抛出几个case（unit testing）并且你debugging到代码和跟踪的时候，它会抛出错误。 你看看你的价值观，并决定他们是对还是错。 这在一定程度上是unit testing。
这里的unit testing实际上正在采取这种行为，将其forms化为结构化模式并进行保存，以便您可以轻松地重新运行这些testing。 如果你写了一个“适当”的unit testing用例而不是手动testing，那么需要花费相同的时间，或者在你经历过的时候花费更less的时间，而且你可以一次又一次地重复
多年来，我试图说服人们，他们需要为他们的代码编写unit testing。 无论他们是先编写testing（如在TDD中）还是在编写function之后，我总是试着向他们解释unit testing代码的所有好处。 几乎没有人不同意我的看法。 你不能不同意一些明显的东西，聪明的人会看到unit testing和TDD的好处。
unit testing的问题在于需要改变行为，很难改变人的行为。 用词，你会得到很多人同意你的看法，但是你不会看到他们做事情的方式有很多的变化。
你必须通过这样做来说服人们。 你个人的成功将会比你所有的争论更多地吸引人们。 如果他们看到你不仅仅是在谈unit testing或者TDD，而是你在做你所说的话，并且你成功了，那么人们会试着模仿你。
你也应该担当主angular，因为没有人第一次写unit testing，所以你可能需要指导他们如何去做，向他们展示他们的方式，以及他们可用的工具。 帮助他们编写第一次testing，复习他们自己写的testing，并通过自己的经验向他们展示你学到的技巧，成语和模式。 过了一段时间，他们将开始看到自己的好处，他们将改变他们的行为，将unit testing或TDD纳入他们的工具箱。
变化不会在一夜之间发生，但有一点耐心，你可能会达到你的目标。
经常被掩盖的testing驱动开发的主要部分是编写可testing的代码。 起初似乎是某种妥协，但是你会发现可测代码最终也是模块化的，可维护的和可读的。 如果你仍然需要帮助说服人们， 这是一个关于unit testing优点的简单介绍。
如果您现有的代码库不适用于unit testing，并且已经投入使用，那么您可能会创build更多的问题，而不是通过尝试重构所有代码来解决问题，从而使其成为单元可testing的问题。
您可能会更好地努力改善您的集成testing。 这里有很多代码，如果没有unit testing，编写起来更简单，如果QA可以根据需求文档validationfunction，那么就完成了。 装运它。
在我看来，这是一个典型的例子，它是一个SqlDataReaderembedded在一个ASPX页面中，链接到一个GridView。 代码全部在ASPX文件中。 SQL是在一个存储过程中。 你是什么unit testing？ 如果页面做了它应该做的事情，你是否应该将它重新devise成多个层次，以便你有自动化的东西？
unit testing最好的一件事就是你的代码将会变得更容易testing。 在没有testing的情况下创build的代码始终是一个挑战，因为既然它们不是要进行unit testing的，那么在类之间进行高级耦合并不难，例如在类中难以configuration的对象 – 比如电子邮件发送服务引用 – 等等。 但不要让这让你失望！ 你会发现，当你开始编写unit testing时，你的整体代码devise会变得更好，而且你testing得越多，你就越有信心做更多的更改，而不用担心会打破你的应用程序或引入错误。
unit testing你的代码有几个原因，但随着时间的推移，你会发现你节省testing的时间是最好的理由之一。 在我刚刚交付的一个系统中，我坚持要进行自动化的unit testing，尽pipe声称我花更多的时间做testing，而不是通过手动testing系统。 随着我所有的unit testing的完成，我在不到10分钟的时间内运行了400多个testing用例，而且每次我只需要对代码进行一些小小的修改就能确保代码仍在工作，分钟。 你能想象一下，人们花时间手工运行这400多个testing用例吗？
当涉及到自动化testing时（无论是unit testing还是验收testing），如果您只打算一次运行testing，那么所有人都认为编写手动代码的做法是浪费时间的，有时也是如此。 自动化testing的最好的部分是你可以毫不费力地运行几次，在第二次或第三次运行之后，你浪费的时间和精力已经付清了。
最后一条build议不仅是unit testing你的代码，而且首先开始testing（请参阅TDD和BDD了解更多信息）
unit testing在重构或重写代码时也特别有用。 如果你有很好的unit testing覆盖率，你可以放心地重构。 没有unit testing，通常很难确保你没有破坏任何东西。
总之 – 是的。 他们值得每一盎司的努力…一点。 testing是在一天结束时仍然是代码，很像典型的代码增长，你的testing最终将需要重构，以保持可持续性。 有一吨GOTCHAS！ 当谈到unit testing，但是男人哦，男人哦，没有什么，我的意思是什么都没有，让一个开发者比一套丰富的unit testing更自信地做出改变。
我现在正在进行一个项目……这是TDD，我们的大部分业务规则都被封装为testing……我们现在有大约500个unit testing。 在过去的迭代中，我必须修改我们的数据源，以及我们的桌面应用程序如何与数据源连接。 花了我好几天的时间，我一直在不停地进行unit testing，看看我弄坏了什么，并修复了它。 做出改变; build立和运行你的testing; 修复你打破了什么。 清洗，冲洗，必要时重复。 传统上需要花费几天的时间才能完成质量保证，而船上的压力则是短暂而愉快的体验。
预先准备好一点点额外的努力，当你不得不开始挑战核心特性/function的时候，它会支付10倍的费用。
我买了这本书 – 这是xUnittesting知识的圣经 – 这可能是我书架上最引用的书籍之一，我每天都去查阅： 链接文本
有时候，我自己或者我的一个同事会花费几个小时才能find一个稍微模糊的bug，一旦发现错误的原因是90％的代码没有经过unit testing。 unit testing是不存在的，因为开发人员为了节省时间而偷工减料，但是随后又放松了这个以及更多的debugging。
花费less量时间编写unit testing可以节省将来debugging的时间。
我正在做一个logging不好，可怕和庞大的代码库的维护工程师。 我希望编写代码的人为它编写unit testing。
每次我进行更改和更新生产代码时，我很害怕我可能会引入一个没有考虑到某种情况的错误。
如果他们编写testing，对代码库的更改将变得更简单和更快（同时代码库将处于更好的状态）。
我认为unit testing在编写必须持续多年的api或框架以及被原始编码人员以外的人员使用/修改/演进时certificate是非常有用的。
unit testing绝对是值得的。 不幸的是，您已经select了一个难以实现的难题（但不幸的是常见）。
从unit testing中得到的最大好处就是从头开始使用它 – 在一些小的项目中，我已经很幸运地在实现我的类之前编写了unit testing（这个界面已经在此完成了点）。 通过适当的unit testing，您可以发现并修复class级中的错误，而这些错误仍然处于起步阶段，并且不会在复杂系统附近的任何地方出现，这些错误无疑将会在未来融入其中。
如果你的软件是坚实的面向对象的，你应该能够在课堂上增加unit testing，而不需要太多的努力。 如果你不是那么幸运的话，你应该尽可能地把unit testingjoin进来。 确保当你添加新的function时，新的function定义清晰的界面，你会发现unit testing让你的生活变得更容易。
当你说，“我们的代码库不适合简单的testing”是代码异味的第一个标志。 编写unit testing意味着您通常编写代码的方式不同，以使代码更易于testing。 在我看来，这是一件很好的事情，正如我多年来在编写代码时看到的那样，我不得不为之编写testing，这迫使我提出了一个更好的devise。
我不知道。 很多地方都不做unit testing，但是代码质量还是不错的。 微软做unit testing，但是比尔·盖茨在演讲中给了蓝屏。
我写了一个关于这个话题的非常大的博客文章。 我发现，单靠unit testing是不值得的工作，通常在截止date越来越近时被削减。
我们不应该从“后验”的validationangular度谈论unit testing，而应该考虑在实施之前着手编写规范/testing/想法时发现的真实价值。
这个简单的想法改变了我写软件的方式，我不会回到“老”的方式。
如何testing第一次发展改变了我的人生
是的 – unit testing绝对是值得的努力，但你应该知道这不是一个银弹。 unit testing是工作，你将不得不努力工作，以保持testing更新和相关的代码更改，但提供的价值是值得你必须投入努力。重构与逍遥法外的能力是一个巨大的好处，因为你总是可以validationfunction在任何更改代码之后运行您的testing。 诀窍就是不要过分地关注你正在testing的工作单元，或者你是如何搭buildtesting需求，以及unit testing是否真的是一个functiontesting等等。人们会争论几个小时实际情况是，你作为你的代码编写的任何testing都比不这样做。 另一个公理是关于质量而不是数量 – 我已经看到了基于1000个testing的代码基本上是毫无意义的，因为其余的testing并没有真正testing任何有用的东西或任何领域特定的像特定领域的业务规则等。 我也看过代码库的代码覆盖率为30％，但testing是相关的，有意义的，真的很棒，因为他们testing了代码的核心function，并表示应该如何使用代码。
在探索新的框架或代码库时，我最喜欢的技巧之一是编写unit testing来“发现”事情的工作方式。 这是一个很好的方式来学习更多的东西，而不是阅读干文档:)
我最近在工作中遇到了同样的经历，发现他们中的大多数人都知道理论上的好处，但是必须特别向他们出售这些好处，所以这里是我使用（成功）的要点：
- 在执行负面testing时，您可以节省时间，您可以在这里处理意外的input（空指针，超出边界值等），因为您可以在一个进程中完成所有这些操作。
- 他们在编译时就变化的标准提供即时反馈。
- 它们对于testing在正常运行时间期间可能不会暴露的内部数据表示是有用的。
和大的…
- 你可能不需要unit testing，但是当其他人进来修改代码而没有完全理解时，它可以捕捉到许多他们可能犯的愚蠢的错误。
几年前，我发现了TDD，并用它写了我所有的宠物项目。 我估计TDD项目需要大致相同的时间才能把它们整合在一起，但是我对最终产品的信心越来越强烈，所以我无法形成一种成就感。
我也觉得它改进了我的devise风格（如果我需要嘲笑事物的话，更多的是面向界面的），正如上面的绿色post所写，它有助于“编码便秘”：当你不知道什么时候要写下，否则你面前有一个艰巨的任务，你可以写小。
最后，我发现到目前为止，TDD最有用的应用是在debugging中，因为你已经开发了一个询问框架，你可以通过这个框架来促使项目以可重复的方式产生bug。
没有人提到过的一件事是获得所有开发人员实际运行和更新任何现有的自动化testing的承诺。 自动化的testing，你回到发现由于新的发展中断，失去了很多的价值，使自动化testing真的很痛苦。 由于开发人员已经手动testing了这些代码，所以大部分这些testing都不会显示错误，所以更新它们的时间只是浪费。
说服怀疑者不要毁掉其他人在unit testing中所做的工作对于从testing中获得价值更为重要，并且可能更容易。
花费数小时更新每次从存储库进行更新时由于新function而中断的testing既不富有成效也不好玩。
如果你正在使用NUnit，一个简单而有效的演示就是在它们前面运行NUnit自己的testing套件。 看到一个真正的testing套件给代码库锻炼是值得千言万语…
unit testing对比任何一个开发人员都能掌握的项目都要有帮助。 他们允许您在签入之前运行unit testing套件，并发现是否破坏了某些东西。 在等待其他人修复他们签入的错误时，不得不坐下来扭动你的拇指，或者为了恢复他们的改变而烦恼，这样你就可以完成一些工作。 它在重构中也非常有价值，所以你可以确定重构的代码通过了原代码所做的所有testing。
使用unit testing套件，可以对代码进行更改，同时保留其他function不变。 这是一个很大的优势。 当您完成编码新function时，您是否使用unit testingsutie和回归testing套件？
我同意大多数人的观点： 可以不写unit testing特别是原型编程（例如AI）很难与unit testing相结合。
