单元测试值得付出努力吗?

单元测试的一个好处是，它们可以作为说明代码行为方式的文档。好的测试有点像参考实现，团队成员可以通过查看它们来了解如何将他们的代码与您的代码集成。

单元测试的全部意义在于使测试变得简单。这是自动的。“make test”就完成了。如果您面临的问题之一是难以测试代码，那么这就是使用单元测试的最佳理由。

最好的说服方式是……找到一个bug，为它写一个单元测试，修复这个bug。

这个特定的错误不太可能再次出现，您可以通过测试来证明它。

如果你做得足够多，其他人很快就会明白。

你想说服谁?工程师还是经理?如果你试图说服你的工程师同事，我认为你最好的办法是迎合他们的愿望，让他们做出高质量的软件。有许多研究表明，它能发现漏洞，如果他们关心做好工作，这对他们来说就足够了。

如果您试图说服管理层，您将很可能不得不做一些成本/收益推理，说明未检测到的缺陷的成本大于编写测试的成本。一定要把不可转化的成本也包括在内，比如失去客户的信心等等。

如果你正在使用NUnit，一个简单而有效的演示就是在他们面前运行NUnit自己的测试套件。看到一个真正的测试套件对代码库进行测试，胜过千言万语……

当您手动测试软件时，通常会使用一小组测试/操作。最终，您将自动修改输入数据或操作，以便围绕已知问题进行导航。应该有单元测试来提醒您某些事情不能正常工作。

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

作为一名物理专业的学生，我非常热衷于证明，因为我的代码可以正常工作。您可以从逻辑上证明这一点，随着实现变得更加复杂，难度会急剧增加，或者您可以通过良好的测试对功能进行(尽可能接近的)经验证明。

如果不提供函数的逻辑证明，就必须进行测试。唯一的选择是说“我认为代码可以工作....”

如果您现有的代码库本身不适合单元测试，并且它已经处于生产环境中，那么通过试图重构所有代码以使其具有单元可测试性，您可能会产生比解决更多的问题。

您最好将精力放在改进集成测试上。有很多代码在没有单元测试的情况下编写起来更简单，如果QA可以根据需求文档验证功能，那么就完成了。船。

在我的脑海中，最经典的例子就是嵌入到GridView的ASPX页面中的SqlDataReader。代码都在ASPX文件中。SQL位于存储过程中。你做什么单元测试?如果页面做了它应该做的事情，那么是否真的应该将其重新设计成几个层，以便实现自动化?

单元测试最好的事情之一是，你的代码会变得更容易测试。在没有测试的情况下创建的预先存在的代码总是一个挑战，因为它们并不意味着要进行单元测试，因此类之间存在高度耦合、类内部难以配置的对象(如电子邮件发送服务引用)等情况并不少见。但不要让这件事打倒你!当您开始编写单元测试时，您将看到您的整体代码设计将变得更好，并且测试得越多，您就越有信心对其进行更多更改，而不必担心破坏应用程序或引入错误。

对代码进行单元测试的原因有很多，但随着时间的推移，您会发现这样做的最佳理由之一是节省测试时间。在我刚刚交付的一个系统中，我坚持进行自动化的单元测试，尽管有人声称我将花费比手动测试系统更多的时间来进行测试。在完成所有单元测试后，我在不到10分钟的时间内运行了400多个测试用例，每次我必须对代码做一个小的更改，我只需要10分钟就可以确保代码仍然可以正常工作，没有错误。您能想象手动运行400多个测试用例所花费的时间吗?

当涉及到自动化测试——无论是单元测试还是验收测试——每个人都认为编写可以手动完成的代码是浪费精力，有时这是真的——如果你计划只运行一次测试的话。自动化测试最好的部分是，您可以毫不费力地运行它们几次，并且在第二次或第三次运行之后，您已经为浪费了付出了时间和精力。

最后一个建议是，不仅要对代码进行单元测试，而且要先进行测试(更多信息请参阅TDD和BDD)

当涉及到重构或重写一段代码时，单元测试也特别有用。如果您有良好的单元测试覆盖率，您就可以满怀信心地进行重构。如果没有单元测试，通常很难确保您没有破坏任何东西。

对于任何一个开发人员都无法想象的大项目，单元测试有很大帮助。它们允许您在签入之前运行单元测试套件，并发现是否破坏了某些东西。这减少了一个很多的例子，因为你不得不坐在那里无所事事，等待别人修复他们检入的错误，或者为了完成一些工作而去恢复他们的更改。它在重构中也非常有价值，因此您可以确保重构的代码通过了原始代码所经过的所有测试。

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

从单元测试中获得的最大好处是从头开始使用它——在一些精选的小项目中，我有幸在实现类之前编写单元测试(此时接口已经完成)。通过适当的单元测试，您可以在类还处于婴儿期时就发现并修复它们，而不是在将来毫无疑问会集成到复杂系统中的任何地方。

如果您的软件是完全面向对象的，那么您应该能够在类级别上添加单元测试，而不需要太多的努力。如果您没有那么幸运，您仍然应该尽可能地尝试合并单元测试。确保当你添加新功能时，新部分都有清晰的接口，你会发现单元测试让你的工作变得更容易。

在我们的办公室里，每天都有这样的对话:

“伙计，我就是喜欢单元测试，我刚刚能够对某些东西的工作方式进行了一系列更改，然后能够通过再次运行测试来确认我没有破坏任何东西……”

细节每天都在变化，但情绪却不变。单元测试和测试驱动开发(TDD)有很多隐藏的和个人的好处，也有很多明显的好处，除非他们自己做，否则你无法真正向他们解释。

但是，忽略这一点，下面是我的尝试!

1. 单元测试允许您快速对代码进行大的更改。您知道它现在可以工作，因为您已经运行了测试，当您进行所需的更改时，您需要让测试再次工作。这样可以节省时间。

2. TDD帮助你意识到何时停止编码。您的测试让您有信心，您现在已经做得足够多了，可以停止调整并转向下一件事情。

3. 测试和代码一起工作以获得更好的代码。你的代码可能很糟糕/有bug。你的测试可能很糟糕/有bug。在TDD中，你指望 是坏的/ bug是低的。通常是测试需要修正，但这仍然是一个好的结果。

4. TDD有助于编码便秘。当你面对一项庞大而艰巨的工作时，编写测试可以让你快速前进。

5. 单元测试帮助您真正理解正在处理的代码的设计。您不是编写代码来执行某些操作，而是首先概述代码所服从的所有条件，以及期望从中得到什么输出。

6. 单元测试给你即时的视觉反馈，我们都喜欢当我们完成时那些绿灯的感觉。非常令人满意。在被打断后重新开始也更容易，因为你可以看到你要去哪里——下一个需要修理的红灯。

7. 与流行的观点相反，单元测试并不意味着编写两倍的代码或更慢的编码。一旦你掌握了它的窍门，它比没有测试的编码更快、更健壮。测试代码本身通常相对简单，不会给您所做的工作增加很大的开销。这句话只有在你做的时候你才会相信:)

8. 我记得Fowler曾说过:“经常运行的不完美测试，比从未编写的完美测试要好得多。”我将此理解为允许我在我认为最有用的地方编写测试，即使我的其余代码覆盖率非常不完整。

9. 好的单元测试可以帮助记录和定义应该做什么

10. 单元测试有助于代码重用。将代码和您的测试迁移到新项目中。调整代码直到测试再次运行。

我参与的很多工作都没有很好地进行单元测试(web应用程序用户交互等)，但即使如此，我们在这个商店里都被测试感染了，当我们把测试束缚住时，我们最高兴。我怎么极力推荐这种方法都不为过。

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

在单元测试之前，我可以非常准确地预测编写代码所需的时间，但无法预测调试所需的时间。

现在，因为我可以计划将要编写什么测试，所以我知道编码需要多长时间，并且在编码结束时，系统已经调试好了!这为开发过程带来了可预见性，消除了许多压力，但仍然保留了所有的乐趣!!

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

回归测试消除恐惧 对代码进行更改(什么都没有 就像看到代码的温暖光芒 每次有变化，要么工作，要么爆发 李)< / > <李> # EYZ0 其他团队成员(包括你自己) 6个月的时间..)
• < em >无情的< / em >重构 -这是令人难以置信的奖励，尝试一下!

代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关单元测试fixture的代码片段并不困难。

简而言之——是的。它们值得你付出每一分努力……在某种程度上。在一天结束的时候，测试仍然是代码，并且很像典型的代码增长，您的测试最终将需要重构，以便可维护和可持续。有一大堆的陷阱!当涉及到单元测试时，但是没有什么，我的意思是没有什么比丰富的单元测试集更能让开发人员更自信地进行更改了。

我现在正在做一个项目....它有点像TDD，而且我们的大部分业务规则都被封装成测试……我们现在有大约500个单元测试。在过去的迭代中，我不得不修改我们的数据源，以及我们的桌面应用程序如何与该数据源接口。我花了几天时间，我一直在运行单元测试，看看我破坏了什么，然后修复它。做出改变;构建并运行测试;修理你弄坏的东西。清洗，冲洗，必要时重复。传统上需要花费数天时间进行QA和承受大量压力的游戏现在变成了短暂而愉快的体验。

提前准备，一点点额外的努力，当你不得不开始摆弄核心特性/功能时，它会给你带来十倍的回报。

我买了这本书——它是xUnit测试知识的圣经——它可能是我书架上被引用最多的书之一，我每天都在查阅它:链接文本

你应该尽量少测试!

这意味着，您应该编写足够多的单元测试来揭示意图。这一点经常被掩盖。单元测试的成本很高。如果您进行了更改，并且必须更改测试，那么您将不那么敏捷。保持单元测试短小精悍。这样它们就有很大的价值。

我经常看到许多永远不会崩溃的测试，它们又大又笨拙，没有提供太多价值，它们最终只会拖慢你的速度。

使用单元测试套件，可以在保持其余功能不变的情况下对代码进行更改。这是一个很大的优势。当你完成新功能的编码时，你会使用单元测试套件和回归测试套件吗?

是的——单元测试绝对值得付出努力，但你应该知道它不是万能的。单元测试是一项工作，你必须在代码发生变化时保持测试的更新和相关性，但它所提供的价值值得你付出努力。不受惩罚的重构能力是一个巨大的好处，因为您可以在任何更改代码后运行测试来验证功能。诀窍是不要太纠结于你正在测试的工作单元，或者你是如何搭建测试需求的，以及什么时候一个单元测试真的是一个功能测试等等。人们会为此争论几个小时，而事实是，在编写代码时做任何测试都比不做要好。另一个公理是关于质量而不是数量的——我曾经见过有1000个测试的代码库，它们本质上是没有意义的，因为剩下的代码库并没有真正测试任何有用的东西，或者任何特定领域的东西，比如业务规则等。我也见过代码库有30%的代码覆盖率，但测试是相关的，有意义的，非常棒的，因为他们测试了代码的核心功能，并表达了代码应该如何使用。

在探索新的框架或代码库时，我最喜欢的一个技巧是为“它”编写单元测试，以发现事物是如何工作的。这是一个学习新事物的好方法，而不是阅读枯燥的文档:)

我最近在我的工作场所经历了完全相同的经历，发现大多数人都知道理论上的好处，但必须具体地向他们推销这些好处，所以下面是我使用的(成功地)要点:

• 它们在执行负测试(处理意外输入(空指针、越界值等)时节省了时间，因为您可以在单个进程中完成所有这些。
• 它们在编译时提供关于更改标准的即时反馈。
• 它们对于测试在正常运行时可能不会公开的内部数据表示非常有用。

还有那个大的…

• 您可能不需要单元测试，但是当其他人进入并在没有完全理解的情况下修改代码时，它可以捕捉到他们可能犯的许多愚蠢的错误。

当你说“我们的代码库不适合简单的测试”时，这是代码气味的第一个迹象。编写单元测试意味着您通常以不同的方式编写代码，以使代码更具可测试性。在我看来，这是一件好事，因为多年来我在编写代码时看到我必须为其编写测试，这迫使我提出更好的设计。

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

单元测试的问题在于它需要行为上的改变，而要改变人们的行为是非常困难的。用语言，你会让很多人同意你的观点，但你不会看到他们做事的方式有太多变化。

你必须通过行动来说服人们。你的个人成功会比你的争论吸引更多的人。如果他们看到你不只是在谈论单元测试或TDD，而是在做你鼓吹的事情，而且你是成功的，人们就会试图模仿你。

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

改变不会在一夜之间发生，但只要有一点耐心，你就可能实现你的目标。

你知道这对你有好处，所有的争论都有道理，所以你开始锻炼。刚开始有一种冲动，这很好，但几天后你开始怀疑是否值得这样做。你每天花一个小时换衣服，在仓鼠转轮上跑步，你不确定除了腿和手臂疼痛之外，你真的得到了什么。

然后，也许一两周后，就在疼痛消失的时候，一个重要的截止日期开始来临。你需要把醒着的每一个小时都用来完成“有用的”工作，所以你要去掉无关紧要的事情，比如去健身房。你改掉了这个习惯，当截止日期结束的时候，你又回到了起点。如果你设法回到健身房，你会觉得和你第一次去的时候一样酸痛。

你读了一些书，看看你是否做错了什么。你开始对所有那些健康、快乐的人赞美运动的好处感到有点不理智的怨恨。你意识到你们没有太多共同之处。他们不必开15分钟的车去健身房;他们楼里就有一个。他们不需要和任何人争论锻炼的好处;这是每个人都会做并且认为很重要的事情。当一个重要的截止日期临近时，他们不会被告知锻炼是不必要的，就像你的老板不会让你停止进食一样。

如果你在一个不重视代码质量的公司中处理面条般的代码库，单元测试可能需要大量的努力。(许多经理会歌颂单元测试，但这并不意味着他们会在关键时刻支持单元测试。)

如果你正试图将单元测试引入到你的工作中，并且没有看到你所期待的所有阳光和彩虹，不要责怪自己。你可能需要找一份新工作来真正让单元测试为你工作。

偶尔，我自己或我的同事会花几个小时来研究一个不太明显的错误，一旦发现了错误的原因，90%的情况下代码都没有经过单元测试。单元测试并不存在，因为开发人员为了节省时间而偷工减料，但随后却失去了这一点和更多的调试。

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

thetalkingwalnut问道:

有什么好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值?

这里的每个人都会突然罗列出单元测试的优点。然而，我发现通常说服别人的最好方法是对他们的论点听，并逐点解决它。如果你倾听并帮助他们表达他们的担忧，你就能解决每一个问题，也许还能把他们转变成你的观点(或者至少，让他们没有立足之处)。不太可能，但有可能。也许如果你发表了他们反对单元测试的论点，我们可以帮助识别相反的论点。

倾听和理解双方的观点是很重要的。如果你太热衷于采用单元测试而不考虑人们的担忧，你将以一场宗教战争告终(而且可能真的毫无价值的单元测试)。如果您慢慢地采用它，并在以最少的成本获得最大收益的地方开始应用它，那么您可能能够证明单元测试的价值，并有更好的机会说服人们。我意识到这并不像听起来那么容易——它通常需要一些时间和仔细的衡量标准来制定一个令人信服的论点。

单元测试是一种工具，就像任何其他工具一样，应该以这样一种方式进行应用，即收益(捕捉错误)大于成本(编写它们的工作)。如果它们没有意义，就不要使用它们，记住它们只是你工具库的一部分(例如检查、断言、代码分析器、形式化方法等)。我告诉开发者的是:

1. 他们可以跳过为一个方法写测试，如果他们有一个很好的理由，为什么这个方法没有必要(例如，太简单了，不值得做或太难了，不值得做)，以及如何验证这个方法(例如，检查，断言，形式化方法，交互/集成测试)。他们需要考虑一些验证，如检查和形式证明是在某个时间点完成的，然后需要在每次生产代码更改时重复执行，而单元测试和断言可以用作回归测试(编写一次并在之后重复执行)。有时我同意他们的观点，但更多时候我会争论一个方法对于单元测试来说是太简单还是太难了。

   • 如果开发人员认为一个方法似乎太简单而不会失败，难道不值得花60秒为它编写一个简单的5行单元测试吗?这5行代码将在接下来的一年或更长的时间里每晚运行(您进行夜间构建，对吗?)，即使只是偶然发现一个可能需要花费15分钟或更长时间来识别和调试的问题，这些努力也是值得的。此外，编写简单的单元测试会增加单元测试的数量，这让开发人员看起来很好。

   • 另一方面，如果开发人员认为某个方法对于单元测试来说太难了(不值得花费大量精力进行单元测试)，也许这是一个很好的迹象，表明需要对该方法进行划分或重构，以测试简单的部分。通常，这些方法依赖于不寻常的资源，如单例、当前时间或外部资源，如数据库结果集。这些方法通常需要重构为一个获取资源的方法(例如调用getTime())和一个以资源为参数的方法(例如以时间戳为参数)。我让他们跳过了对检索资源的方法的测试，而是为现在将资源作为参数的方法编写了一个单元测试。通常，这使得单元测试的编写更加简单，因此值得编写。

   李< / ul > < / >

   • 开发人员需要在单元测试的全面程度上画一条“界限”。在开发的后期，每当我们发现bug时，他们应该确定更全面的单元测试是否已经发现了问题。如果是这样，如果这样的错误反复出现，他们就需要把“路线”转向将来编写更全面的单元测试(从为当前的错误添加或扩展单元测试开始)。他们需要找到正确的平衡。

重要的是要意识到单元测试不是万能的，而且有太多的单元测试。在我的工作场所，每当我们做一个经验教训，我不可避免地听到“我们需要写更多的单元测试”。管理层点头表示同意，因为“单元测试”==“好”这句话已经被灌输到他们的头脑中了。

然而，我们需要理解“更多单元测试”的影响。一个开发人员一周只能写N行代码，你需要弄清楚单元测试代码和生产代码所占的比例。一个松散的工作场所可能有10%的代码作为单元测试，90%的代码作为生产代码，导致产品有很多(尽管非常有bug)的特性(想想微软的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的问题。t对每个Foo。PM的代码库，它做:

  use_ok( 'Foo' );
  

• Is all the POD (Plain Ol' Documentation) formatted properly? Use Test::Pod to validate the validity of the formatting of all the POD in all the files.

You may not think these are big things, and they're not, but I can guarantee you will catch some slop. When these tests run once an hour, and it catches someone's premature commit, you'll have people say "Hey, that's pretty cool."

我在其他答案中没有看到这一点，但我注意到我可以更快地调试。你不需要通过正确的步骤序列深入到你的应用程序中，只发现你犯了一个布尔错误，需要重新做一遍。使用单元测试，您可以直接进入正在调试的代码。

单元测试适用于QA人员或你的经理，而不是你;所以绝对不值得。

您应该专注于编写正确的代码(不管这意味着什么)，而不是测试用例。让其他人去担心吧。

单元测试可以帮助您以更少的错误发布软件，同时降低总体开发成本。您可以点击链接阅读更多关于单元测试的好处

我曾多次尝试单元测试，我仍然相信，考虑到我的情况，这是值得的。

我开发网站，其中很多逻辑涉及在数据库中创建、检索或更新数据。当我为了单元测试的目的而尝试“模拟”数据库时，它变得非常混乱，似乎有点毫无意义。

当我围绕业务逻辑编写单元测试时，从长远来看它从未真正帮助过我。因为我主要独自从事项目工作，我倾向于直观地知道哪些代码区域可能会受到我所从事的工作的影响，并且我手动测试这些区域。我希望尽可能快地向客户交付解决方案，而单元测试通常看起来是浪费时间。我列出了手动测试，并亲自完成它们，并在执行过程中标记它们。

我可以看到，当一个开发团队在一个项目中工作并互相更新代码时，这可能是有益的，但即使这样，我认为如果开发人员具有高质量，良好的沟通和编写良好的代码通常就足够了。

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

我在几年前发现了TDD，从那时起我就使用它编写了所有我喜欢的项目。我估计，TDD一个项目所花费的时间与牛仔式地组合一个项目所花费的时间大致相同，但我对最终产品的信心增加了，以至于我忍不住有一种成就感。

我还觉得它改进了我的设计风格(更面向界面，以防我需要一起模拟东西)，而且，正如顶部的绿色帖子所写的，它有助于“编码便秘”:当你不知道接下来要写什么，或者你有一个令人生畏的任务摆在你面前时，你可以写小一点的。

最后，我发现到目前为止，TDD最有用的应用是在调试中，如果仅仅因为您已经开发了一个询问框架，那么您就可以用它来刺激项目以可重复的方式产生错误。

[我有一个观点，我不能在上面看到]

“每个人都在进行单元测试，他们不一定意识到这一点——事实”

想想看，你写了一个函数来解析一个字符串并删除新的行字符。作为一个开发新手，你要么在命令行中通过Main()实现它来运行几个用例，要么用一个按钮组合一个可视化前端，将你的函数绑定到几个文本框和一个按钮上，然后看看会发生什么。

这就是单元测试——基本的和糟糕的组合在一起，但是你测试了一些情况下的代码段。

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

这里的单元测试实际上是采用这种行为，将其形式化为结构化模式并保存，以便您可以轻松地重新运行这些测试。如果您编写了一个“适当的”单元测试用例而不是手动测试，那么它所花费的时间是相同的，或者随着您的经验的增加可能会更少，并且您可以一次又一次地重复它

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

这是非常以。net为中心的，但是有人尝试过Pex吗?

我非常怀疑，直到我尝试了——哇，多么精彩的表演。之前我想过“我不会被这个概念说服，直到我明白做对我有什么好处”。我只运行了一次就改变了主意，说:“我不知道护理你怎么知道那里有致命异常的风险，但是有是，现在我知道我必须处理它。”

也许这种行为的唯一缺点是它会标记一切并给你六个月的积压。但是，如果你有代码债，你总是有代码债，只是你不知道而已。告诉PM可能有20万个故障点，而你之前只知道几十个，这是一个令人讨厌的前景，这意味着概念是首先解释道。是至关重要的

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

相反，功能测试是针对用户的:无论何时添加功能测试，您都是在测试用户将看到的东西。当您添加单元测试时，您只是让开发人员的生活更轻松。在这方面有点奢侈。

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

关于这个话题，我写了一篇很大的博客文章。我发现单靠单元测试是不值得的，而且通常在截止日期临近时就会被削减。

与其从“测试后验证”的角度来讨论单元测试，我们应该看看在实现之前编写规范/测试/想法时所发现的真正价值。

这个简单的想法改变了我写软件的方式，我不会回到“旧的”方式。

test first开发如何改变了我的生活

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

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

一旦开发人员知道如果单元测试失败，他们就不必花那么多时间调试它来发现问题，他们就会更有动力去编写这些测试。

这里有一个工具可以提供这样的功能:

单元测试回归分析工具

@George Stocker“不幸的是，我们的代码库并不适合简单的测试。”每个人都同意单元测试有好处，但对于这个代码库来说，成本似乎很高。如果成本大于收益，那么他们为什么要对此充满热情呢?倾听你同事的意见;也许对他们来说，单元测试的痛苦比单元测试的价值更大。

具体地说，尽量尽快获得价值，而不是一些感觉良好的“xUnit是绿色的”价值，而是用户和维护者所重视的干净代码。也许您必须为一次迭代强制进行单元测试，然后讨论是否值得这样做。

我同意与大多数人相反的观点: 不写单元测试是可以的 特别是重原型的编程(例如AI)很难与单元测试相结合

还没有人提到的一件事是，让所有开发人员承诺实际运行和更新任何现有的自动化测试。当您重新进行自动化测试并发现由于新的开发而出现故障时，会失去很多价值并使自动化测试非常痛苦。因为开发人员已经手动测试了代码，所以大多数测试不会指出错误，所以花在更新它们上的时间只是浪费。

说服怀疑者不要破坏其他人在单元测试上所做的工作，对于从测试中获得价值更为重要，而且可能更容易。

每次从存储库更新时，花费数小时更新由于新特性而损坏的测试既没有效率也没有乐趣。