我正在努力将单元测试集成到我所工作的团队的开发过程中，并且有些怀疑论者。有什么好的方法可以使怀疑的开发人员相信团队中单元测试的价值？在我的特定情况下，我们将在添加功能或者修复错误时添加单元测试。不幸的是，我们的代码库无法使其易于测试。

解决方案

回答

单元测试的一大优点是它们可作为文档说明代码的行为方式。好的测试有点像参考实现，而队友可以看看他们，看看如何将他们的代码与代码集成在一起。

回答

单元测试的全部目的是使测试变得容易。它是自动化的。 "进行测试"，我们就完成了。如果我们面临的问题之一是难以测试代码，那就是所有使用单元测试的最佳理由。

回答

说服的最佳方法...查找错误，为其编写单元测试，修复该错误。

该特定错误不太可能再次出现，我们可以通过测试来证明。

如果我们这样做足够，其他人将很快赶上。

回答

我们想说服谁？工程师还是经理？如果我们想说服工程师同事，我认为我们最好的选择就是呼吁他们制作高质量软件的愿望。有大量研究表明，它可以发现错误，如果他们关心做好事，那么对他们来说就足够了。

如果我们试图说服管理层，则很可能必须进行某种成本/收益推理，即无法检测到的缺陷的成本大于编写测试的成本。确保也包括可消除的成本，例如失去客户信心等。

回答

通常会掩盖测试驱动开发的主要部分是可测试代码的编写。起初似乎有些妥协，但是我们会发现可测试代码最终还是模块化的，可维护的和可读的。
如果我们仍然需要说服他人的帮助，那么这是一个关于单元测试优点的简单演示。

回答

如果我们使用的是NUnit，则一个简单而有效的演示就是在它们前面运行NUnit自己的测试套件。看到一个真正的测试套件为代码库提供了锻炼，值得一千个单词。

回答

手动测试软件时，通常会使用少量测试/操作。最终，我们将自动使输入数据或者操作变形，以便我们在已知问题中导航。单元测试应该在那里，以提醒我们事情无法正常进行。

我建议在代码之前编写测试，添加新的测试/数据以改进主代码的功能！

回答

作为一名物理专业的学生，​​我非常渴望证明自己的代码能够按预期工作。我们可以逻辑地证明这一点，随着实现变得更加复杂，难度会大大增加，或者可以通过良好的测试来(尽可能接近)对功能进行经验证明。

如果我们不提供逻辑上的功能证明，则必须进行测试。唯一的选择是说"我认为代码有效。。。"

回答

如果我们现有的代码库不适合进行单元测试，并且已经在生产中，则可能会尝试重构所有代码以使其可以进行单元测试，从而造成比解决方案更多的问题。

我们最好将精力放在改善集成测试上。那里有很多无需单元测试就可以编写的代码，如果QA可以根据需求文档验证功能，那么我们就完成了。装运它。

我想到的经典示例是嵌入到链接到GridView的ASPX页面中的SqlDataReader。该代码全部在ASPX文件中。 SQL在存储过程中。我们要进行什么单元测试？如果页面做了应有的功能，我们是否应该将页面真正地重新设计为几层，以便进行自动化处理？

回答

关于单元测试的最好的事情之一就是代码将随着测试变得更加容易。在没有测试的情况下创建的预先存在的代码始终是一个挑战，因为由于它们并不是要进行单元测试的，因此在类之间，类内部难以配置的对象(如电子邮件发送)之间进行高级别的耦合并不罕见服务的参考等。但是，不要让这让我们失望！我们会发现，随着开始编写单元测试，总体代码设计会变得更好，并且测试越多，我们就越有信心对它进行更多更改，而不必担心会破坏应用程序或者引入错误。 。

对代码进行单元测试的原因有很多，但是随着时间的推移，我们会发​​现节省测试时间是最好的理由之一。在我刚刚交付的系统中，尽管我声称与手动测试系统相比，我花更多的时间进行测试，但我仍坚持进行自动化的单元测试。随着我所有的单元测试完成后，我在不到10分钟跑400多的测试案例，每一次我不得不这样做在代码的微小变化，都花了我一定的代码仍然没有错误工作十岁分钟。我们能想象一个人花时间手动运行这400多个测试用例吗？

当涉及到自动化测试时，无论是单元测试还是验收测试，每个人都认为浪费精力来编写我们可以手动执行的操作，有时，如果我们计划只运行一次测试，那是真的。自动化测试的最好之处在于，我们可以毫不费力地运行它们几次，并且在第二次或者第三次运行之后，我们已经浪费了时间和精力。

最后一条建议是不仅要对代码进行单元测试，而且还要先开始进行测试(有关更多信息，请参见TDD和BDD)

回答

当涉及重构或者重写一段代码时，单元测试也特别有用。如果我们具有良好的单元测试覆盖范围，则可以放心地进行重构。没有单元测试，通常很难确保我们没有破坏任何东西。

回答

单元测试对大于任何开发人员所能承受的项目有很大帮助。它们使我们可以在签入之前运行单元测试套件，并发现是否损坏了某些内容。这样就减少了很多事情，不必坐下来动一下手指，而又等待其他人修复他们签入的错误，或者麻烦恢复他们的更改，以便我们可以完成一些工作。它在重构中也非常有价值，因此我们可以确保重构后的代码能够通过原始代码所做的所有测试。

回答

单元测试绝对值得付出努力。不幸的是，我们选择了一个困难的(但不幸的是很常见)的方案来实现它。

我们将获得的单元测试的最大好处是，在一些精选的小型项目中完全使用它时，我很幸运在实现类之前就编写了单元测试(此时接口已经完成了) )。通过适当的单元测试，我们将在班级中仍处于初级阶段的错误中找到并修复错误，并且这些错误几乎不会在将来毫无疑问地集成到复杂的系统中。

如果软件是面向对象的，那么我们应该能够在类级别上添加单元测试，而无需花费太多精力。如果不是那么幸运，那么我们仍然应该尽可能尝试合并单元测试。确保在添加新功能时，使用清晰的界面就可以很好地定义新部件，并且会发现单元测试使工作变得更加轻松。

回答

每天我们办公室里都有这样的交流活动：

"Man, I just love unit tests, I've just been able to make a bunch of changes to the way something works, and then was able to confirm I hadn't broken anything by running the test over it again..."

细节每天都在变化，但是情绪却没有变化。单元测试和测试驱动的开发(TDD)具有许多隐藏的和个人的好处，以及显而易见的好处，我们只是在他们自己做到之前就无法真正向他人解释。

但是，忽略这一点，这是我的尝试！

• 单元测试使我们可以快速更改代码。我们知道它现在可以工作，因为我们已经运行了测试，在进行需要进行的更改时，需要使测试重新开始工作。这样可以节省时间。
• TDD可了解何时停止编码。通过测试，我们可以确信自己已经做了足够的工作，并且可以停止调整并继续进行下一步。
• 测试和代码可以一起工作以获得更好的代码。代码可能是错误的/错误的。测试可能是错误/错误的。在TDD中，我们认为坏/越野车的几率很低。通常，这是需要修复的测试，但这仍然是一个很好的结果。
• TDD帮助便秘编码。面对大量艰巨的工作，编写测试将使我们快速前进。
• 单元测试可真正了解正在处理的代码的设计。我们无需编写代码来执行某些操作，而是首先概述要使代码遵循的所有条件以及从中获得的期望输出。
• 单元测试为我们提供即时的视觉反馈，我们都喜欢完成后所有这些绿灯的感觉。非常令人满意。中断后在哪里停下来也容易多了，因为我们可以看到到达的地方–下一个需要修复的红灯。
• 与流行的信念单元测试相反，这并不意味着编写两倍的代码或者编写速度较慢的代码。一旦掌握了它，它比没有测试的编码更快，更强大。测试代码本身通常是相对琐碎的，不会增加工作量。这是我们只有在执行此操作时才会相信的方法:)
• 我认为正是福勒说："经常运行的不完美测试比根本没有编写的完美测试要好得多"。我认为这是允许我在我认为最有用的地方编写测试，即使余下的代码覆盖范围很不完整。
• 好的单元测试可以帮助记录和定义应该做什么
• 单元测试有助于代码重用。将代码和测试都迁移到新项目中。调整代码，直到测试再次运行。

我参与的很多工作都无法很好地进行单元测试(Web应用程序用户交互等)，但是即使如此，我们在这家商店中都受到了测试的感染，而当我们将测试捆绑在一起时，这是最快乐的。我不能高度推荐这种方法。

回答

单元测试的好处之一是可预测性。

在进行单元测试之前，我本可以在很大程度上准确地预测编写某些东西将花费多长时间，而不是调试它需要多少时间。

这些天来，由于我可以计划要编写的测试，因此我知道编码需要花费多长时间，并且在编码结束时，系统已经调试完毕！这为开发过程带来了可预测性，它消除了很多压力，但仍然保留了所有乐趣！！

回答

单元测试非常值得初始投资。自几年前开始使用单元测试以来，我发现了一些真正的好处：

• 回归测试消除了对代码进行更改的担心(没有像每次执行更改时看到代码正常工作或者爆炸一样的热情洋溢的感觉)
• 其他团队成员(以及我们自己在六个月的时间内..)的可执行代码示例
• 无情的重构-这是令人难以置信的收获，请尝试！

代码段可以极大地减少创建测试的开销。创建片段可以在几秒钟内创建类大纲和相关的单元测试夹具，这并不难。

回答

总之是的。在某种程度上，它们值得每一刻的努力。最终，测试仍然是代码，就像典型的代码增长一样，最终将需要重构测试以保持可维护性和可持续性。一吨的GOTCHAS！当涉及到单元测试时，但是，天哪，没什么，我的意思是，NOTHING比一组丰富的单元测试更能使开发人员更自信地进行更改。

我现在正在开发一个项目...。它有点像TDD，并且我们将大多数业务规则封装为测试...我们现在有大约500个左右的单元测试。在过去的迭代中，我不得不修改数据源以及桌面应用程序与该数据源的接口。花了我几天的时间，整个过程中，我一直在运行单元测试，以查看发生了什么问题并进行修复。做出改变;建立并运行测试；修理你弄坏的东西。洗涤，漂洗，根据需要重复。传统上需要几天的质量检查和大量的压力，这是一次短暂而愉快的经历。

预先做好准备，需要付出一些额外的努力，当我们不得不开始关注核心功能时，它需要支付10倍的费用。

我买了这本书，这是一本有关xUnit Testing的圣经，可能是我架上参考最多的书之一，我每天都在阅读它：链接文本

回答

我们应该尽可能少地进行测试！

意思是，我们应该编写足够的单元测试以显示意图。这经常被掩盖。单元测试使我们费钱。如果我们进行更改并且必须更改测试，那么敏捷性就会降低。保持单元测试简短有趣。然后，它们具有很大的价值。

我经常看到很多测试永远不会失败，又大又笨拙，并且没有提供太多价值，它们只会使速度变慢。

回答

借助单元测试套件，我们可以对代码进行更改，同时保持其余功能不变。这是一个很大的优势。完成新功能编码后，是否使用单元测试支持和回归测试套件。

回答

是的，单元测试绝对值得付出努力，但我们应该知道这不是万灵丹。单元测试是可行的，我们将必须努力保持测试的更新和代码变化的相关性，但是所提供的价值值得我们付出努力。不受惩罚的重构能力是一项巨大的好处，因为我们可以始终验证功能在任何更改代码之后运行测试。诀窍是不要过于迷恋正在测试的工作单元或者如何架设测试需求，以及何时单元测试确实是功能测试等。人们会在数小时内争论这些问题。最后，现实是我们在编写代码时进行的任何测试总比不进行测试要好。另一个公理是关于质量而不是数量，我看到的代码库具有1000的测试本质上是没有意义的，因为其余代码实际上并没有测试任何有用的东西或者特定领域的任何特定领域，例如业务规则等。我也看到过代码库覆盖了30％的代码，但是这些测试是相关的，有意义的，并且确实很棒，因为它们测试了所编写代码的核心功能并表达了应如何使用该代码。

在探索新框架或者代码库时，我最喜欢的技巧之一是为" it"编写单元测试，以发现事物的工作方式。这是一种学习更多新知识的好方法，而不是阅读干燥的文档:)

回答

最近，我在工作场所经历了完全相同的经历，发现他们中的大多数人都知道理论上的好处，但是必须将这些好处专门卖给他们，所以这是我(成功地)使用的要点：

• 它们可以在执行否定测试时节省时间，在此我们可以处理意外输入(空指针，超出范围的值等)，因为我们可以在单个过程中完成所有这些操作。
• 它们在编译时提供有关更改标准的即时反馈。
• 它们对于测试在正常运行时可能不会公开的内部数据表示形式很有用。

还有那个大...

• 我们可能不需要单元测试，但是当其他人进入并修改代码而又不完全理解时，它可能会捕获很多他们可能犯的愚蠢错误。

回答

当我们说"我们的代码库无法使其易于测试"时，这是代码气味的第一个迹象。编写单元测试意味着我们通常以不同的方式编写代码，以使代码更具可测试性。在我看来，这是一件好事，因为多年来我在编写不得不编写测试的代码时看到了这一点，这迫使我提出更好的设计。

回答

多年以来，我一直试图说服人们他们需要为其代码编写单元测试。无论他们是先编写测试(如在TDD中)，还是在编写功能代码之后，我总是试图向他们解释为代码进行单元测试的所有好处。几乎没有人不同意我。我们不能不同意显而易见的事情，任何聪明的人都会看到单元测试和TDD的好处。

单元测试的问题在于它需要改变行为，并且很难改变人们的行为。用言语，我们会得到很多人的同意，但是我们做事的方式不会看到很多变化。

我们必须通过这样做来说服人们。我们个人的成功将吸引更多的人，而不是我们可能拥有的所有论点。如果他们看到我们不仅在谈论单元测试或者TDD，而且我们正在做自己的演讲，并且我们成功了，那么人们会尝试模仿我们。

我们还应该担任领导角色，因为没有人第一次正确地编写单元测试，因此我们可能需要指导他们如何进行单元测试，向他们展示方法以及可用的工具。在他们编写第一个测试时帮助他们，回顾他们自己编写的测试，并向他们展示我们通过自己的经验中学到的技巧，习语和模式。一段时间后，他们将开始自己看到收益，并且他们将改变其行为，以将单元测试或者TDD纳入其工具箱。

改变不会在一夜之间发生，但是只要有一点耐心，我们就可以实现自己的目标。

回答

单元测试很像去体育馆。我们知道这对我们有好处，所有论点都是有道理的，因此我们开始锻炼。最初很急，这很不错，但是几天后，我们开始怀疑这是否值得解决。我们每天要花一个小时的时间去换衣服并在仓鼠轮子上奔跑，我们不确定除了腿和胳膊酸痛以外，我们还能获得其他好处。

然后，大概一两个星期后，就在酸痛消失的时候，一个大限期开始临近。我们需要花每个醒来的时间来尝试完成"有用的"工作，因此我们要切掉多余的内容，例如去健身房。我们已经习惯了，到"大限期"结束时，我们将回到第一位。如果我们设法将其重新回到健身房，我们会感到与第一次去时一样疼痛。

我们需要阅读一些内容，以查看是否做错了什么。开始时，我们会感到一些不合情理的恶作剧对所有健康，快乐的人赞美运动的美德。我们意识到自己没有太多共同点。他们不必开车15分钟就能去健身房。他们的大楼里有一个。他们不必与任何人争论运动的好处。这只是每个人都做并被接受为重要的事情。当"大限期"临近时，他们不会被告知没有必要做运动，而老板会要求我们停止进食。

因此，为回答问题，单元测试通常值得我们付出努力，但是所需的努力量对每个人来说都不尽相同。如果我们在一家实际上并不重视代码质量的公司中处理意大利面条代码库，则单元测试可能需要大量的精力。 (很多经理都会赞扬单元测试的赞美，但这并不意味着他们会坚持下去。)

如果我们试图将单元测试引入工作中，但是没有看到我们期望的所有阳光和彩虹，请不要怪自己。我们可能需要找到一份新工作才能真正使单元测试为我们工作。

回答

有时候，我本人或者我的一位同事都会花费几个小时来探究稍微模糊的错误的根源，一旦找到了错误的原因，则有90％的时间未对代码进行单元测试。单元测试不存在，因为开发人员在偷工减料以节省时间，但随后又放开了它并进行了更多调试。

花很少的时间编写单元测试可以节省数小时的未来调试时间。

回答

thetalkingwalnut asks:
  
  
    What are some good ways to convince the skeptical developers on the team of the value of Unit Testing?

这里的每个人都会出于很多原因而突然想到单元测试良好的原因。但是，我发现，说服某人某事的最好方法通常是听取他们的论点并逐点解决。如果我们倾听并帮助他们表达他们的疑虑，则可以解决每个问题，并可能将其转换为观点(或者至少让他们站不住脚)。谁知道？也许他们会说服我们为什么单元测试不适合情况。不太可能，但是可能。也许，如果我们发布他们针对单元测试的论点，我们可以确定反论点。

聆听和理解论证的两面很重要。如果我们过于热心地采用单元测试而不考虑人们的担忧，那么我们将陷入一场宗教战争(并且可能真的是毫无价值的单元测试)。如果我们慢慢地采用它，并从最低的成本获得最大收益的地方开始应用它，我们也许能够证明单元测试的价值，并更有说服力的机会。我意识到这并不像听起来那么容易，通常需要一些时间和谨慎的指标来提出令人信服的论点。

单元测试是一种工具，与其他任何工具一样，应以这样的方式进行应用：收益(捕获错误)超过成本(编写代码的工作量)。如果它们在没有意义的地方使用，请不要使用它们，并记住它们只是我们工具库中的一部分(例如检查，断言，代码分析器，形式化方法等)。我告诉开发人员的是：

• 另一方面，如果开发人员认为一种方法似乎很难进行单元测试(不值得进行大量工作)，那么这可能很好地表明该方法需要进行分解或者重构以测试易用的部件。通常，这些方法依赖于诸如单例，当前时间之类的异常资源，或者诸如数据库结果集之类的外部资源。这些方法通常需要重构为获取资源的方法(例如调用getTime())和将资源作为参数的方法(例如以时间戳作为参数)。我让他们跳过测试检索资源的方法，而是为现在将资源作为参数的方法编写单元测试。通常，这使编写单元测试变得更加简单，因此值得编写。
• 开发人员需要在单元测试的全面程度上划清界线。在开发的后期，每当我们发现错误时，他们都应确定是否进行更全面的单元测试可以解决问题。如果是这样，并且如果此类错误反复出现，则它们需要朝着将来编写更全面的单元测试的方向(从为当前错误添加或者扩展单元测试开始)。他们需要找到适当的平衡。

实现单元测试的重点不是万能的，而是存在太多的单元测试之类的东西。在我的工作场所，每当我们吸取教训时，我都会不可避免地听到"我们需要编写更多的单元测试"。管理层点头表示同意，因为它被人们嘲笑为"单元测试" =="好"。

但是，我们需要了解"更多单元测试"的影响。开发人员一个星期只能编写约N行代码，我们需要弄清楚该代码占单元测试代码与生产代码的比例是多少。宽松的工作场所可能有10％的代码作为单元测试，而90％的代码作为生产代码，从而导致产品具有很多(尽管很容易出错)功能(例如MS Word)。另一方面，拥有90％的单元测试和10％的生产代码的严格车间将拥有功能很少的坚如磐石的产品(请考虑" vi")。我们可能永远不会听到有关后一种产品崩溃的报告，但这可能与该产品的销量不佳以及与代码质量的影响不一样。

更糟糕的是，也许软件开发中的唯一确定性是"改变是不可避免的"。假设严格的车间(90％的单元测试/ 10％的生产代码)创建的产品具有完全2个功能(假设5％的生产代码== 1个功能)。如果客户出现并更改其中一项功能，那么更改将浪费50％的代码(45％的单元测试和5％的生产代码)。宽松的工厂(10％的单元测试/ 90％的生产代码)的产品具有18个功能，但都无法很好地发挥作用。他们的客户完全改变了其4种功能的要求。即使更改的大小是原来的4倍，也只会浪费一半的代码库(〜25％=〜4.4％单元测试+ 20％的生产代码)。

我的观点是，我们必须传达自己的意思，即我们了解在问题的两个方面都考虑过的，太少和太多的单元测试之间的平衡。如果我们可以说服同龄人和/或者管理层，那么我们将获得信誉，并且可能更有机会赢得他们。

回答

使我们要测试的第一件事与单元测试无关。我主要在Perl工作，因此这些是Perl特定的示例，但是我们可以适应。

• 是否每个模块都能正确加载和编译？在Perl中，这是在执行以下操作的代码库中为每个Foo.pm创建一个Foo.t的问题：

use_ok( 'Foo' );

• 是否所有POD(普通Ol'文档)的格式都正确？使用Test :: Pod来验证所有文件中所有POD格式的有效性。

我们可能不会认为这些是大事，但事实并非如此，但我可以保证我们会遇到一些麻烦。当这些测试每小时运行一次，并且捕获到某人的过早提交时，我们会让人说："嘿，这很酷。"

回答

我在其他任何答案中都没有看到这一点，但是我注意到的一件事是，我可以更快地进行调试。我们不需要按照正确的步骤顺序来深入研究应用程序即可得到要修复的代码，只需发现我们犯了布尔错误，然后需要重新做一次即可。通过单元测试，我们可以直接进入要调试的代码。

回答

单元测试仅适用于质量检查人员或者经理，而不适用于我们。因此绝对不值得。

我们应该专注于编写正确的代码(无论它意味着什么)，而不是测试用例。让其他人担心这些。

回答

单元测试可发布具有更少错误的软件，同时降低总体开发成本。我们可以单击链接以了解有关单元测试的好处的更多信息

回答

我多次玩过单元测试，但仍然可以相信，根据我的情况，这样做是值得的。

我开发网站，其中许多逻辑涉及创建，检索或者更新数据库中的数据。当我试图"模拟"数据库以进行单元测试时，它变得非常混乱，似乎毫无意义。

当我围绕业务逻辑编写单元测试时，从长远来看，它并没有真正帮助我。因为我主要是独自从事项目工作，所以我倾向于直观地知道哪些代码区域可能受到我正在处理的内容的影响，因此我手动测试了这些区域。我想尽快为客户提供解决方案，而单元测试通常看起来很浪费时间。我列出了手动测试，并亲自完成了这些测试，并在进行过程中将其选中。

我可以看到，当一个开发人员团队从事一个项目并更新彼此的代码时，这可能是有益的，但是即使如此，我仍然认为，如果开发人员的素质很高，那么良好的沟通和良好的编写代码通常就足够了。 。

回答

我正在做一个记录不佳，糟糕而又庞大的代码库的维护工程师。我希望编写代码的人已经为此编写了单元测试。
每当我进行更改并更新生产代码时，我都会担心由于未考虑某些条件而可能引入错误。
如果他们编写了测试，则对代码库的更改将变得更加容易和快捷(同时，代码库将处于更好的状态)。

我认为单元测试在编写必须持续多年并且要由原始编码人员以外的人员使用/修改/发展的api或者框架时非常有用。

回答

几年前，我发现了TDD，从那时起，我就使用它编写了所有宠物项目。我估计完成TDD项目和共同完成牛仔项目大约需要相同的时间，但是我对最终产品的信心越来越大，以至于我不禁感到成就感。

我还感觉到它改善了我的设计风格(在需要一起模拟的情况下，更多的是面向接口的)，并且，如顶部的绿色文章所述，它有助于"编码便秘"：当我们不知道什么接下来写，或者我们面前有艰巨的任务，可以写小写。

最后，我发现到目前为止，TDD最有用的应用是在调试中，这仅仅是因为我们已经开发了一个查询框架，利用该框架我们可以促使项目以可重复的方式产生错误。

回答

[我要指出的是，我在上面看不到]

"每个单元测试，他们不一定都意识到这一点"

考虑一下，我们编写了一个函数来解析字符串并删除换行符。作为新手开发人员，我们可以通过在Main()中实现它来从命令行运行一些案例，也可以通过按钮将视觉前端组合在一起，将函数绑定到几个文本框和一个按钮，然后查看怎么了。

那是单元测试的基础，很难组合在一起，但是我们只在少数情况下测试了这段代码。

我们写的东西更复杂。当我们通过一些案例(单元测试)并调试到代码并进行跟踪时，它将引发错误。我们在浏览过程中会查看值，并确定它们是对还是错。这是某种程度上的单元测试。

这里的单元测试实际上就是采取这种行为，将其形式化为结构化模式并保存下来，以便我们可以轻松地重新运行这些测试。如果我们编写一个"适当的"单元测试用例而不是手动测试，那么它所花费的时间是相同的，或者可能比我们所经历的要少，并且可以重复一次。

回答

我不知道。很多地方不做单元测试，但是代码的质量很好。微软进行单元测试，但是比尔·盖茨在演讲中给出了蓝屏。

回答

就在今天，我不得不更改先前已为其编写单元测试的类。
该测试本身写得很好，并包含了我什至没有想到的测试方案。
幸运的是，所有测试都通过了，我的更改得到了快速验证，并充满信心地投入了测试环境。

回答

这是非常以.Net为中心的，但是有人尝试过Pex吗？

在尝试并哇之前，我一直持怀疑态度，真是太好了。在我以为"直到我了解它真正使我受益的真正意义上，我才不会被这个概念所吸引"。我花了一个单一的时间就改变了主意，说："我不在乎我们怎么知道那里有致命异常的危险，但是现在我知道我必须处理它。"

也许这种行为的唯一缺点是它将标记所有内容并为我们提供六个月的积压。但是，如果我们有代码债务，那么我们总会有代码债务，我们只是不知道。告诉PM潜在的20万个故障点是在我们不知道几十个故障之前是一个令人讨厌的前景，这意味着首先解释这个概念至关重要。

回答

关于单元测试要记住的一件事是，这对开发人员来说是一种安慰。

相反，功能测试是针对用户的：无论何时添加功能测试，都在测试用户将看到的内容。添加单元测试时，我们只是在简化开发人员的生活。在这方面有点奢侈。

当我们必须在编写单元测试或者功能测试之间做出选择时，请记住这种二分法。

回答

我写了一篇有关该主题的大型博客文章。我发现单靠单元测试是不值得的，通常会在截止日期临近时被削减。

而不是从"测试后"验证的角度谈论单元测试，我们应该查看在开始实施之前编写规范/测试/想法时发现的真实值。

这个简单的想法改变了我编写软件的方式，并且我不会回到"旧"方式。

测试第一次开发如何改变了我的生活

回答

根据我的经验，在复杂的软件环境中，单元测试和集成测试是"必须具备的"。

为了说服团队中的开发人员编写单元测试，我们可能需要考虑在开发环境中(例如，在日常构建过程中)集成单元测试回归分析。

一旦开发人员知道如果单元测试失败，那么他们就不必花费大量的时间调试它来发现问题，那么就会鼓励他们编写它们。

这是提供此类功能的工具：

单元测试回归分析工具

回答

@George Stocker"不幸的是，我们的代码库无法使其易于测试。"每个人都同意单元测试有好处，但听起来对于此代码库而言，成本很高。如果成本大于收益，那么为什么他们应该对此充满热情呢？听你的同事；也许对他们来说，单元测试的痛苦大于单元测试的感知价值。

具体来说，请尝试尽快获取价值，而不是获得一些" xUnit是绿色"的感觉，而是获取用户和维护者重视的干净代码。也许我们必须强制进行一次单元测试，然后讨论是否值得付出努力。