Is Unit Testing worth the effort?
我正在努力将单元测试集成到我所工作的团队的开发过程中，并且有一些怀疑论者。有哪些好方法可以让团队中持怀疑态度的开发人员相信单元测试的价值？在我的具体案例中，我们将在添加功能或修复错误时添加单元测试。不幸的是，我们的代码库不适合进行简单的测试。
我们办公室每天都有这样的交流：
"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应用程序用户交互等)，但即便如此，我们都在这家商店中受到了测试感染，当我们的测试被捆绑时，我们最高兴。我不能高度推荐这种方法。
单元测试很像去健身房。你知道这对你有好处，所有的争论都是有意义的，所以你开始锻炼。有一个最初的匆忙，这是伟大的，但几天后，你开始怀疑它是否值得麻烦。你每天要花一个小时换衣服，骑着仓鼠轮子跑，你不确定除了腿和胳膊酸痛以外，你真的得到了什么。
然后，也许一两周后，就在疼痛消失的时候，一个大的最后期限就要到来了。你需要把每一个醒着的时间都花在完成"有用的"工作上，这样你就省去了一些无关的事情，比如去健身房。你不再习惯了，到了最后期限，你又回到正轨了。如果你能回到健身房，你会和第一次去的时候一样感到疼痛。
你读点书，看看你是否做错了什么。你开始觉得有点无理的怨恨，对所有健康、快乐的人赞美运动的优点。你知道你没有很多共同点。他们不必开15分钟的车去健身房，他们的大楼里有一个健身房。他们不必和任何人争论运动的好处；这是每个人都做的，也被认为是重要的事情。当一个重要的最后期限临近时，他们不会被告知锻炼是不必要的，这比你的老板要求你停止进食的次数还要多。
所以，为了回答您的问题，单元测试通常是值得努力的，但是所需的努力对于每个人来说都不一样。如果您在一家实际上并不重视代码质量的公司中处理意粉代码库，那么单元测试可能需要大量的工作。(很多经理都会对单元测试赞不绝口，但这并不意味着他们会在重要的时候坚持下去。)
如果你试图在你的工作中引入单元测试，却没有看到你所期望的所有阳光和彩虹，不要责怪你自己。您可能需要找到一个新的工作来真正使单元测试为您工作。
最好的说服方法…找到一个bug，为它编写一个单元测试，修复这个bug。
这个特定的bug不太可能再次出现，您可以通过测试来证明它。
如果你做的足够多，其他人会很快赶上。
thetalkingwalnut asks:
Ok.
What are some good ways to convince the skeptical developers on the team of the value of Unit Testing?
Ok.
< /块引用>
这里的每个人都会不知所措地提出很多理由来说明为什么单元测试是好的。然而，我发现，让某人相信某件事的最好方法往往是倾听他们的论点，并逐点加以解决。如果你倾听并帮助他们描述他们的问题，你可以解决每一个问题，也许可以将它们转化为你的观点(或者至少，让他们没有一条腿可以站立)。谁知道呢？也许他们会说服你为什么单元测试不适合你的情况。不太可能，但可能。也许，如果您将它们的参数发布到单元测试中，我们可以帮助识别反参数。好的。
倾听和理解争论的双方是很重要的。如果你过于热心地采用单元测试，而不考虑人们的担忧，那么你最终会陷入一场宗教战争(可能真的是毫无价值的单元测试)。如果你慢慢地采用它，并且从你认为成本最低的地方开始应用它，你可能能够证明单元测试的价值，并且有更好的机会说服人们。我意识到这并不像听起来那么简单——通常需要一些时间和仔细的衡量标准来制定一个令人信服的论点。好的。
与其他任何工具一样，单元测试也是一种工具，其应用方式应使好处(捕获bug)大于成本(编写它们的工作)。如果它们没有意义，不要使用它们，记住它们只是工具库的一部分(例如检查、断言、代码分析器、正式方法等)。我告诉我的开发人员：好的。
他们可以跳过为一个方法编写测试，如果他们有一个很好的论据，为什么不必要(例如，太简单而不值得或太难值得)以及如何以其他方式验证该方法(例如，检查、断言、正式方法、交互/集成测试)。他们需要考虑一些验证，比如检查和正式的证明，是在某个时间点完成的，然后在每次生产代码更改时都需要重复，而单元测试和断言可以用作回归测试(编写一次，然后重复执行)。有时我同意他们的观点，但更经常的是我会争论一个方法是否真的太简单或太难进行单元测试。好的。
如果一个开发人员认为一个方法似乎太简单而不能失败，那么花60秒为它编写一个简单的5行单元测试难道不值得吗？这5行代码将每晚运行(您每晚都进行构建，对吗？)在接下来的一年或更久的时间里，即使只是一次偶然发现了一个可能需要15分钟或更长时间来识别和调试的问题，也值得付出努力。此外，编写简单的单元测试会增加单元测试的数量，这使开发人员看起来很好。好的。
另一方面，如果开发人员认为某个方法似乎太难进行单元测试(不值得花费大量的精力)，那么这可能是一个很好的迹象，表明需要对该方法进行划分或重构以测试容易的部分。通常，这些方法依赖于异常资源，如单例、当前时间或外部资源(如数据库结果集)。这些方法通常需要重构为获取资源的方法(例如，调用getTime())和将资源作为参数的方法(例如，将时间戳作为参数)。我让他们跳过对检索资源的方法的测试，而是为现在将资源作为参数的方法编写一个单元测试。通常，这会使编写单元测试变得更简单，因此值得编写。好的。
开发者需要在单元测试的综合程度上划出一条"沙线"。在稍后的开发中，每当我们发现一个bug时，他们应该确定是否更全面的单元测试会发现这个问题。如果是这样，如果这种错误反复出现，他们需要在将来将"一行"移到编写更全面的单元测试(从为当前错误添加或扩展单元测试开始)。他们需要找到正确的平衡。好的。
重要的是要认识到单元测试不是一个银弹，还有一件事就是单元测试太多了。在我的工作场所，每当我们吸取教训时，我不可避免地听到"我们需要编写更多的单元测试"。管理层点头表示同意，因为"单元测试"被敲进了他们的脑袋。好的。
但是，我们需要了解"更多单元测试"的影响。开发人员一周只能编写~n行代码，您需要计算出单元测试代码与生产代码的百分比。一个松散的工作场所可能有10%的代码作为单元测试，90%的代码作为生产代码，从而导致产品具有许多(尽管非常糟糕)特性(想想MS Word)。另一方面，一个严格的车间，90%的单元测试和10%的生产代码，将会有一个功能非常少的坚如磐石的产品(想想"vi")。您可能永远不会听到关于后一种产品崩溃的报告，但这很可能与产品销售不太好有关，而与代码质量有关。好的。
更糟糕的是，也许软件开发中唯一确定的是"变化是不可避免的"。假设Strict Shop(90%单元测试/10%生产代码)创建的产品正好具有2个功能(假设5%的生产代码=1个功能)。如果客户出现并更改了1个特性，那么这一更改将丢弃50%的代码(45%的单元测试和5%的生产代码)。LAX车间(10%的单元测试/90%的生产代码)有一个具有18个功能的产品，这些功能都不能很好地工作。他们的客户完全修改了4个功能的要求。即使更改的大小是4倍，但只有一半的代码库会被破坏(约25%=约4.4%的单元测试+20%的生产代码)。好的。
我的观点是，你必须交流你理解在太少和太多单元测试之间的平衡——本质上是你已经考虑过了问题的两面。如果你能说服你的同龄人和/或你的管理层相信这一点，你就获得了信任，也许有更好的机会赢得他们的信任。好的。好啊。
我已经玩弄了很多次单元测试，我仍然相信，考虑到我的情况，这是值得的努力。
我开发网站，其中许多逻辑涉及创建、检索或更新数据库中的数据。当我试图"模拟"用于单元测试的数据库时，它变得非常混乱，似乎有点毫无意义。
当我围绕业务逻辑编写单元测试时，从长远来看，它从未真正帮助过我。因为我主要是单独在项目上工作，所以我倾向于凭直觉知道哪些代码区域可能会受到我正在工作的东西的影响，并且我手动测试这些区域。我想尽快向我的客户交付一个解决方案，而单元测试似乎常常是浪费时间。我列出了手工测试，并亲自进行，在我进行的时候把它们勾掉。
我可以看到，当一个开发团队正在开发一个项目并更新彼此的代码时，这可能是有益的，但即使这样，我认为，如果开发人员是高质量的，良好的沟通和良好的编写代码通常也是足够的。
关于单元测试的一个好处是，它们可以作为代码行为的文档。好的测试有点像一个引用实现，队友可以查看它们，看看如何将它们的代码与您的代码集成在一起。
单元测试非常值得初始投资。自从几年前开始使用单元测试以来，我发现了一些真正的好处：
- 回归测试消除了对对代码进行更改(没有就像看到代码的温暖光芒每次改变都要工作或爆发制造)
- 可执行代码示例其他团队成员(以及你自己六个月时间..)
- 无情的重构-这是非常值得的，试试看！
代码片段可以极大地帮助减少创建测试的开销。创建能够在几秒钟内创建类大纲和相关联的单元测试夹具的代码片段并不困难。
你应该尽可能少地测试！
也就是说，您应该编写足够的单元测试来揭示意图。这经常被掩盖。单元测试会让你付出代价。如果你做了改变，你必须改变测试，你的敏捷性就会降低。保持单元测试的简短和甜蜜。那么它们就有了很大的价值。
我经常看到很多测试永远不会失败，它们又大又笨拙，而且没有提供很多价值，它们最终会让你慢下来。
我没有在其他答案中看到这个问题，但我注意到的一件事是我可以更快地调试。你不需要在你的应用程序中钻取正确的步骤序列来获取你修复的代码，只需要发现你犯了一个布尔错误，需要再次执行所有操作。通过单元测试，您可以直接进入正在调试的代码。
[我有一点要说明，我看不见上面的内容]
"每个人都要进行单元测试，他们不一定意识到这一点-事实"
考虑一下，编写一个函数来解析字符串并删除新行字符。作为一个新手开发人员，您可以通过在main()中实现命令行来运行一些案例，也可以用一个按钮将一个可视前端拼凑在一起，将您的函数绑定到几个文本框和一个按钮上，然后看看会发生什么。
这是单元测试——基本的和糟糕的组合在一起，但是您测试代码的一些情况。
你写的东西更复杂。当您通过(单元测试)抛出一些案例，并且调试到代码中并跟踪时，它会抛出错误。你在经历过程中观察价值观，并决定它们是对的还是错的。这在某种程度上是单元测试。
这里的单元测试实际上是采用这种行为，将其形式化为一个结构化的模式并保存它，以便您可以轻松地重新运行这些测试。如果您编写一个"适当的"单元测试用例而不是手动测试，那么所花费的时间可能与您所经历的时间相同，也可能比您所经历的时间要短，并且您可以反复地重复它。
多年来，我一直试图说服人们，他们需要为代码编写单元测试。无论他们是先编写测试(如在TDD中)，还是在对功能进行编码之后，我总是试图向他们解释为代码进行单元测试的所有好处。几乎没有人反对我。你不能反对一些显而易见的事情，任何聪明人都会看到单元测试和TDD的好处。
单元测试的问题在于它需要行为改变，而且很难改变人们的行为。用语言，你会得到很多人同意你，但你不会看到他们做事的方式有很多变化。
你必须通过行动说服人们。你的个人成功会比你可能拥有的所有论据影响更多的人。如果他们看到你不仅仅是在谈论单元测试或者TDD，而是在做你所宣扬的，并且你是成功的，人们会试图模仿你。
您还应该担任领导角色，因为没有人第一次正确地编写单元测试，所以您可能需要指导他们如何编写单元测试，向他们展示方法，以及他们可用的工具。在他们编写第一个测试时帮助他们，回顾他们自己编写的测试，并向他们展示通过自己的经验学习到的技巧、习惯用法和模式。过了一会儿，他们将开始看到自己的好处，并且他们将改变自己的行为，将单元测试或TDD合并到他们的工具箱中。
改变不会在一夜之间发生，但只要有一点耐心，你就能实现你的目标。
测试驱动开发的一个主要部分经常被掩盖，那就是编写可测试代码。乍一看，这似乎是一种妥协，但您会发现可测试代码最终也是模块化的、可维护的和可读的。如果您仍然需要帮助说服人们，这是一个关于单元测试优点的很好的简单演示。
如果您现有的代码库不适合进行单元测试，并且已经在生产中，那么您可能会通过重构所有代码来创建比解决更多的问题，从而使其可以进行单元测试。
您最好不要拖延改进集成测试的工作。有很多代码没有单元测试就很容易编写，如果QA可以根据需求文档验证功能，那么就完成了。用船装运。
在我看来，典型的例子是嵌入在链接到GridView的ASPX页面中的SQLDataReader。代码都在ASPX文件中。SQL在存储过程中。单元测试是什么？如果页面做了它应该做的事情，您真的应该将它重新设计成多个层，这样您就有了自动化的东西吗？
一个最好的事情是，关于单元测试你的代码会变得更容易吗？两个试验，当你做它。preexisting测试代码创造了没有冰总是一个挑战，因为由于他们不是t意味着两个单元测试，它不好有高水平的两个类之间的耦合，硬configure目标在两类型取决你的电子邮件的货物和服务的在线参考的婊子。但不容易，这给你下！你会看到，你的整体设计将成为更好的代码，当你开始写单元测试，测试和享受你的娱乐，你会成为confident在线制作甚至更换它没有破坏你的恐惧(应用或引入错误。
有两个原因several单元测试你的代码，但随着时间的progresses，你会找到的，在测试时，你的锯冰的一个最好的原因做它。在一个系统中delivered我们真的在做，insisted在线自动单元测试的spite申报，我花的方式有更多的时间做我的城市比测试系统测试的表壳，手动上弦。用我所有的单元测试运行完成，超过400个测试用例，在不到10分钟，每一次的仇恨和两个做一个小的代码变更好，听着，我花了两个酸性的代码是没有错误的工作仍然是十分钟。你能想象这会花两个小时一运行这些测试用例400多个城市的手吗？
当它是自动测试是单元测试或验收测试，每个人都认为这是一个浪费的努力两个代码可以做什么和表壳，手动上弦，有时它的威胁-如果你运行你的测试计划的两个一次。最好的部分是自动测试，你可以跑several时报没有他们的努力，和在第二或第三的运行时间和努力，你已经浪费的冰已支付的。
一块货物的建议将是两个不只是你的代码的单元测试，但测试开始做第一(见TDD和BDD的乐趣)
单元测试是特别有用的也当它是重构或重新写一件一码。如果你有好的单元测试覆盖，你可以重构与信心。没有单元测试，它往往是很难确保《你不打破任何东西。
偶尔，我自己或者我的一个同事会花上几个小时去了解稍微模糊的bug，一旦发现bug的原因，90%的时间代码没有经过单元测试。单元测试不存在，因为开发人员为了节省时间而偷工减料，但随后会失去这一点和更多的调试。
花少量的时间编写单元测试可以节省将来调试的时间。
我是一名维护工程师，有着糟糕的文档记录，糟糕的代码库。我希望编写代码的人已经为它编写了单元测试。每次我进行更改和更新生产代码时，我都担心会因为没有考虑到某些条件而引入错误。如果他们编写测试，对代码库进行更改将变得越来越容易和快速(同时代码库将处于更好的状态)。
我认为在编写API或框架时，单元测试被证明是非常有用的，这些API或框架必须持续很多年，并且必须由原始编码人员以外的人使用/修改/开发。
简而言之——是的。他们值得付出每一盎司的努力…到某一点。测试最终仍然是代码，而且与典型的代码增长非常相似，您的测试最终需要重构，以便能够维护和可持续。有一吨的货物！当涉及到单元测试时，但是，天啊，天啊，什么都没有，我的意思是没有什么比一组丰富的单元测试更能让开发人员自信地进行更改。
我正在做一个项目…它有点像TDD，我们的大部分业务规则都被封装为测试…我们现在有大约500个单元测试。在过去的迭代中，我必须修改数据源，以及桌面应用程序如何与该数据源交互。我花了几天时间，一直在运行单元测试，以查看我损坏了什么并修复它。做一个改变；构建和运行测试；修复你所破坏的。清洗，冲洗，必要时重复。传统上，需要几天的质量保证和船上的压力，而不是一个短暂和愉快的经验。
提前做好准备，做点额外的工作，当你不得不开始讨论核心特性/功能的时候，它会花10倍的钱。
我买了这本书——这是Xunit测试知识的圣经——这可能是我书架上参考最多的书之一，我每天都会查阅它：链接文本
单元测试冰当然值得的努力。只可惜你已经选择了一个难(但不幸的普通的)的情况下，实施这两个词的信息。
最好的效益，从单元测试，你会把它当用冰从地面上的几个小项目，选择，在fortunate已经足够写单元测试，我在我的类实现的接口是完整的。这一点)。用适当的单元测试，你会找到和修复错误在你的类当他们仍然在他们的infancy和没有任何地方近的复杂的系统，他们会成为undoubtedly综合体内的未来"。
如果你的solidly冰的面向对象的软件，你应该能够添加单元测试在类级别，没有太多的努力。如果你不知道fortunate，你应该试图incorporate静态单元测试无论你能做的。确保当你添加新功能性纽约是个好的定义与透明的接口，你会找到单元测试，使你的生活更容易吗？太多了。
当你说，"我们的代码库不适合简单的测试"，这是代码味道的第一个标志。编写单元测试意味着您通常以不同的方式编写代码，以使代码更具可测试性。在我看来，这是一件好事，因为多年来我一直在编写我必须为之编写测试的代码，这迫使我提出了一个更好的设计。
我不知道。很多地方不做单元测试，但是代码的质量很好。微软做了单元测试，但比尔盖茨在他的演示中给出了一个蓝屏。
我写了一篇关于这个主题的非常大的博客文章。我发现单靠单元测试是不值得的，而且通常在最后期限临近时就会被削减。
我们不应该从"测试后"验证的角度来讨论单元测试，而应该看看在您开始编写一个规范/测试/想法时发现的真正值。
这个简单的想法改变了我编写软件的方式，我不会回到"旧"的方式。
测试第一次开发如何改变我的生活
还没有人提到的一件事是让所有开发人员承诺实际运行和更新任何现有的自动化测试。由于新的开发，您返回到的自动化测试会失去很多价值，并使自动化测试非常痛苦。因为开发人员已经手动测试了代码，所以这些测试中的大多数不会指示错误，所以花在更新它们上的时间只是浪费。
说服怀疑论者不要破坏其他人在单元测试中所做的工作，对于从测试中获得价值来说更重要，而且可能更容易。
每次从存储库中更新因新特性而中断的测试都要花费数小时来更新，这既不高效也不有趣。
是的-单元测试确实值得你这么做，但是你应该知道这不是一个银弹。单元测试是有效的，当代码发生变化时，您必须保持测试的更新和相关性，但是提供的值值得您付出努力。不受惩罚地重构的能力是一个巨大的好处，因为您可以通过在任何更改代码之后运行测试来验证功能。诀窍是不要过分依赖于你正在测试的工作单元，或者你是如何构建测试需求的，以及当一个单元测试真的是一个功能测试时，等等。人们会连续几个小时争论这些东西，而事实是，你作为你的写代码所做的任何测试都比不做要好。另一个公理是质量而不是数量——我已经看到了1000次测试的代码基础，这些测试基本上没有意义，因为其余的测试实际上没有测试任何有用的或特定领域的东西，比如特定领域的业务规则等。我也见过代码覆盖率为30%的代码库，但是这些测试是相关的、有意义的，而且非常棒，因为它们测试了为其编写的代码的核心功能，并表示了应该如何使用代码。
在探索新框架或代码库时，我最喜欢的技巧之一是为"it"编写单元测试，以发现事情是如何工作的。这是一个了解更多新事物的好方法，而不是阅读枯燥的医生：)
几年前我发现了TDD，并用它编写了我所有的宠物项目。我估计TDD一个项目所花的时间大致与牛仔项目所花的时间相同，但我对最终产品的信心如此增强，以致于我无法有成就感。
我还觉得它改善了我的设计风格(如果我需要一起模拟的话，它更面向界面)，正如上面的绿色帖子所写，它有助于"编码便秘"：当你不知道下一步要写什么，或者你面前有一个艰巨的任务时，你可以写得很小。
最后，我发现到目前为止，TDD最有用的应用程序是在调试中，如果只是因为您已经开发了一个询问框架，用它可以促使项目以可重复的方式生成bug。
我最近在我的工作场所经历了完全相同的经历，发现大多数人都知道理论上的好处，但必须特别向他们出售好处，因此我使用的要点如下(成功)：
- 它们在执行负测试时节省了时间，在负测试中，您可以处理意外的输入(空指针、越界值等)，因为您可以在单个进程中完成所有这些操作。
- 它们在编译时提供有关更改标准的即时反馈。
- 它们对于测试在正常运行时可能不会公开的内部数据表示形式很有用。
大的那个…
- 您可能不需要单元测试，但是当其他人进来修改代码而没有完全理解时，它会捕获他们可能犯的许多愚蠢错误。
我同意与大多数人相反的观点：不写单元测试没关系尤其是原型重编程(例如ai)很难与单元测试相结合。
如果您正在使用nunit，一个简单但有效的演示就是在它们前面运行nunit自己的测试套件。看到一个真正的测试套件给一个代码库一个锻炼是值得的千言万语…
根据我的经验，在复杂的软件环境中，单元测试和集成测试是"必须具备的"。
为了说服团队中的开发人员编写单元测试，您可能需要考虑在开发环境中(例如，在日常的构建过程中)集成单元测试回归分析。
一旦开发人员知道如果一个单元测试失败了，他们就不必花太多时间调试它来发现问题，那么他们就更愿意编写它们。
以下是提供此类功能的工具：
单元测试回归分析工具
关于单元测试，需要记住的一件事是它对于开发人员来说是一种舒适的体验。
相反，功能测试是针对用户的：无论何时添加功能测试，您都在测试用户将看到的东西。当你添加一个单元测试时，你只是让你作为一个开发人员的生活更容易。在这方面有点奢侈。
当您必须在编写单元或功能测试之间做出选择时，请记住这种二分法。
有了单元测试套件，您可以在保持其余功能不变的情况下对代码进行更改。这是一个很大的优势。完成新特性的编码后，是否使用单元测试Sutie和回归测试套件？
单元测试helps很多的项目，是larger比任何一个团队，开发者可以在他们的头。他们允许你在运行单元测试套件之前，如果你发现checkin和坏的东西。这是下一个批在线切割instances大学有两个旋转和竖起随你在等别人把他们两个A检查在腹，或要去改变他们的hassle大学reverting婊子，你可以得到一些好的工作。它的immensely也有价值的重构，所以你可以重构代码的酸性，照顾所有的测试，没有原代码。
做你测试的第一件与单元测试无关的事情。我主要使用Perl，所以这些都是Perl特有的例子，但是您可以适应。
每个模块是否正确加载和编译？在Perl中，这是为代码库中的每个foo.pm创建foo.t的问题，它可以：
所有的pod(普通的ol'文档)格式是否正确？使用test:：pod验证所有文件中所有pod格式的有效性。
你可能不认为这是大事，但我可以保证你会得到一些马虎。当这些测试每小时运行一次，并且捕捉到某人的过早承诺时，你会让人们说"嘿，那很酷。"
单元测试的一个好处是可预测性。
在单元测试之前，我可以非常准确地预测编码某个东西需要多长时间，但不能预测我需要多长时间来调试它。
这些天，因为我可以计划我要写什么测试，我知道编码需要多长时间，在编码结束时，系统已经调试好了！这给开发过程带来了可预测性，它消除了很多压力，但仍然保留了所有的乐趣！！
就在今天，我不得不更改一个以前编写过单元测试的类。测试本身写得很好，包括了我甚至没有想到的测试场景。幸运的是，所有的测试都通过了，我的更改很快得到了验证，并信心十足地投入到测试环境中。
@乔治·斯托克"不幸的是，我们的代码库不适合进行简单的测试。"每个人都同意单元测试有好处，但是对于这个代码库来说，成本很高。如果成本高于收益，那么他们为什么要对此热情呢？倾听你的同事；也许对他们来说，单元测试的感知痛苦大于单元测试的感知价值。
具体来说，尽量争取尽快获得价值，而不是一些感觉良好的"虚即绿"的价值，而是用户和维护者看重的干净代码。也许你必须为一个迭代授权单元测试，然后讨论它是否值得你去做。
作为一名物理系学生，我非常有动力去证明我的代码是按预期工作的。您可以从逻辑上证明这一点，随着实现变得更加复杂，这将大大增加难度，或者您可以通过良好的测试(尽可能接近)对函数进行经验证明。
如果您不提供逻辑的功能证明，则必须进行测试。唯一的选择是说"我认为代码是有效的……"
当您手动测试软件时，您通常会使用一组小的测试/操作。最终，您将自动变形您的输入数据或操作，以便在已知问题周围导航。单元测试应该在那里提醒您事情不能正常工作。
我建议在代码之前编写测试，添加新的测试/数据以发展主代码的功能！
单元测试的关键是使测试变得容易。它是自动化的。"做测试"你就完成了。如果您面临的问题之一是难以测试代码，那么这就是所有使用单元测试的最佳原因。
这是非常以.NET为中心的，但有人尝试过Pex吗？
我非常怀疑，直到我尝试了它-哇，多棒的表演。在我想"我不会被这个概念所说服，除非我明白它实际上对我有什么好处"。我花了很长时间才改变主意说："我不在乎你怎么知道那里有致命的例外的风险，但现在有了，我知道我必须处理它。"
也许这种行为唯一的缺点是它会标记出所有东西，并给你一个六个月的积压工作。但是，如果你有代码债务，你总是有代码债务，你只是不知道。告诉一个下午有20万个潜在的失败点，当你还没有意识到几十个是一个令人讨厌的前景，这意味着这是至关重要的概念，首先解释。
单元测试可以帮助您以更少的错误发布软件，同时降低总体开发成本。您可以单击链接以了解有关单元测试的好处的更多信息
你想说服谁？工程师还是经理？如果你试图说服你的工程师同事，我认为你最好的选择是吸引他们制作高质量软件的愿望。有许多研究表明它发现了错误，如果他们关心做得好，那对他们来说就足够了。
如果你试图说服管理层，你很可能不得不做某种成本/收益推理，说那些无法被检测到的缺陷的成本大于编写测试的成本。一定要包括可吸收的成本，如失去客户信心等。
单元测试是高质量代码最常用的方法之一。它对更稳定、独立和文档化的代码的贡献已经得到了很好的证明。单元测试代码被视为和处理为存储库的一个组成部分，因此需要开发和维护。然而，开发人员经常遇到这样一种情况，即在单元测试中投入的资源没有人们期望的那么富有成效。在一个理想的世界里，我们编写的每一个方法都会有一系列的测试来覆盖它的代码并验证它的正确性。但是，通常由于时间限制，我们要么跳过一些测试，要么编写质量差的测试。在这种情况下，在考虑投入在单元测试开发和维护上的资源量的同时，必须问自己，考虑到可用的时间，哪种代码最值得测试？从现有的测试来看，哪些测试实际上值得保留和维护？看到这里
单元测试适用于QA人员或您的经理，而不是您；所以它绝对不值得。
您应该专注于编写正确的代码(不管它意味着什么)，而不是测试用例。让其他人担心。