好吧，老实说，我一生中写过的单元测试可能不超过 10 个。
我正在着手一个新项目，作为唯一的程序员意味着我应该害怕......非常害怕。
我可以伪保证我的软件可以工作的想法带来了快乐。
当然，我会错过很多我应该测试的案例，但随着时间的推移，我会在那里学习。
单元测试将帮助我晚上睡得更好，这对我的健康更有好处。
我的代码会失败，但至少我会知道什么时候会失败。
尽管您团队的其他成员没有赶上潮流，但单元测试如何让您的生活变得更好（或者有？）？
【问题讨论】：
标签： unit-testing
单元测试对我的项目最大的价值是信心。有了这种信心，就可以更轻松地添加一开始没有计划的新功能，并拆分代码以更改或扭转局面。
通过测试我知道我（或其他任何人！）没有破坏已经工作的东西。
当你做出重大改变并在下一分钟将它们部署到生产中时，你是勇敢的（或愚蠢的）。
【讨论】：
通过单元测试，我减少了在测试阶段报告的“愚蠢错误”的数量。这也让我对自己的代码更有信心。
【讨论】：
正如 Elie 所说，单元测试是尽早清除“愚蠢”或简单错误的好方法。 对我来说，它改变了我对代码的看法；使我的代码可测试使其不那么脆弱和更灵活（例如，depenceny 注入/控制反转对我来说很自然，因为无论如何我都是为了测试目的而做的）。
我个人从一个完整的测试套件中获得的最大好处是，即使在我编写复杂代码几个月后也有信心更改它，而不必担心意外破坏某些东西。
我还没有到那里，但是在编写它们时有一些纪律，单元测试也是记录代码的好方法。
【讨论】：
好的，因为没有其他人站出来扮演魔鬼的拥护者，我会这样做。
自动化单元测试可以为某些项目带来好处，但也可能存在以下许多问题：
因此，开发人员不应该对单元测试采用教条式（是或否）的方法，而应该对每个项目进行 ROI 计算。
【讨论】：
将单元测试与 TDD 结合使用为我提供了完成手头任务的动力和动力。如果没有写测试、修测试、写测试、修测试的小进步，我会变得没有动力。
【讨论】：
当您开始调试时，单元测试也非常有用。如果您的测试失败，那么您几乎可以立即知道错误在哪里。如果它们都运行，那么您就知道错误在哪里没有（大部分时间）。
单元测试可以帮助的另一个领域：迁移软件。我发现准备将具有单元测试的 Python 代码迁移到 Python 3 比编写没有单元测试的代码要容易得多。
当然，我会错过很多我应该测试的案例，但随着时间的推移，我会在那里学习。
这是测试驱动开发真正闪耀的地方。您不必太担心进行适当的测试，因为该问题会事先为您解答。
当然，为了确保我们在同一个页面上，“测试驱动开发”是指编写测试的编码过程，验证测试是否失败，然后编写代码。
【讨论】：
对我来说，改变我生活的不仅仅是单元测试，还有测试驱动开发 (TDD)。我把它比作我博客文章中的宗教体验（我知道，无耻）My Year with TDD。
参加测试对我来说是一次改变职业生涯的经历。我写的 bug 更少，我写的代码更易读，我写的代码更有凝聚力，我知道什么时候有问题（通常）等等。这一切都归功于测试驱动开发。
试试吧，你喜欢它:)
【讨论】：
自从我在 uni 的第二个*项目（早在 1988 年）以来，我一直是一名 TDD（开发人员）。我不知道那个词当时是否还在使用。
最好的事情是能够改变事物并很快检查你没有破坏其他任何东西。简单的回归测试。
它们也是对象/方法使用的良好文档。
*这直接是因为第一个项目是如何进行的......
【讨论】：
单元测试带给您的最大好处是对代码的信心。你知道东西在一定的质量水平上工作，你知道你可以进去改变或重写一些东西，而不会让事情在你不期望的地方失败。验证只是一个测试。
【讨论】：
现在我培养测试驱动我的代码，我知道我什么时候完成一个函数、一个组件或一个特性。因此我可以准确地报告进度。
我知道这不是没有错误的代码，但它的功能足以集成、构建和交付给 QA。我有信心他们将能够开始测试，而不会被分段错误或任何其他愚蠢的问题所阻止。
我还准备好了一个环境，以便我可以快速编写一个新测试来重现任何将报告的问题，并且我有一个安全网来检测方面我修改或修复代码时的影响和回归。
【讨论】：
不能代表所有人，但我开始编写测试是因为一位开发人员编写的测试对我学习系统有很大帮助。
我还发现，在使用新代码库时，测试是验证假设的好方法。
【讨论】：
单元测试不是灵丹妙药。但它确实有好处，而且非常令人满意。
我发现这意味着我的代码执行得更早了，因为在我编写单元测试之前，需要大量编码才能在应用程序中尝试足够的功能。
当我来重构时，我也非常感谢我的单元测试套件。不久前我重写了一个完整的日期处理模块，如果没有回归测试，我不可能有信心这样做。
【讨论】：
我必须说，我认为 VS 2010 中的改进，例如 Ctrl+Enter（我认为就是这样）可以让您在编写测试时快速存根类的接口（首先）将会让我更轻松。
【讨论】：
单元测试的优势是多方面的。更具体地说，它如何让我的生活变得更好，嗯，我认为它增加了改变的信心，让我有可能在以后更快地改变代码。从长远来看，它会增加我的生命。
当然，我可以在很短的时间内告诉它，这会更痛苦，因为它需要更多时间，但是当你在进行这些测试时自动验证自己时，它很快就会被遗忘。
【讨论】：
我是单元测试的忠实拥护者，虽然我的测试现在不能提供完整的覆盖范围......主要是因为我在一个网站上工作，而我的大部分代码只是从数据库中获取数据并对其进行操作，然后吐出来。操作代码通常经过良好测试，但测试数据库代码确实很痛苦。
话虽如此，我可以指出一个案例，单元测试为我节省了数周的工作......
不久前，我正在从事一个小型项目（4-6 个开发人员），经过几个月的工作，我们已经接近完成的状态。此时，负责该产品的人员决定，与其在 GMT 中存储日期（并使用它们生成报告），不如在 EST 中存储所有内容。鉴于该产品旨在处理大量数据/日志并根据时间范围生成有关该数据的信息，因此这是一个相当大的变化。
在接下来的几天里，开发团队介入并更改了所有内容以处理 EST 时间戳。如果我们没有进行如此广泛的自动化测试，我们会花费数周时间完成的工作，只用了 3 天，让我们能够满足紧迫的时间表。我们能够跳入代码并开始更改我们需要的任何内容；单元测试给了我们勇气，因为我们知道如果我们破坏了某些东西，系统会很快抱怨。直到今天，我仍以那次经历为例，说明在自动化测试拯救你之前，你永远无法真正理解自动化测试的好处……而且它确实为我的团队做到了这一点。
【讨论】：
我目前正在尝试赶上潮流。工作伙伴在编写一行功能代码之前就已经在这样做了。在我通过主程序运行它之前，我仍在编写一个完整的程序，更不用说单元测试了：/
我敢肯定，我最终会到达那里。但目前，我的身体状况不佳，90% 的时间都在调试：(
【讨论】：
我在 java 方面做了很多工作，在 Ruby 方面做了一年。
在 Ruby 中，我们使用了广泛的测试 (TDD)。这是绝对需要的。您可以将几乎完整的垃圾代码写入 Ruby 文件，如果您没有点击特定的代码行，您将永远不会知道，因此您的测试需要接近 100% 的覆盖率。
在 Java 中，我只需要一个简单的成功路径测试——而且通常可以在代码运行后丢弃。真正使这成为可能的是静态类型检查、强类型和使用编码模式（如强封装和参数检查）。你实际上可以非常接近证明一个小类在没有测试的情况下不能被破坏（没有错误），并且如果设计正确，所有类都应该是小的。
另一个兴趣点：在 Ruby 项目中，我们进行了一次重构，花费了 2 天的实际代码工作（将主要模型类分成两个类）和 2 周的测试修复。
在某些时候，所有这些测试都是有代价的，它们仍然是你必须维护的代码。
也就是说，我发现 TDD 很有趣，而且是开始工作的好方法，即使在 Java 中也是如此，我还要重申，我至少总是有一些成功路径测试（即使它只是一种快速的主要方法）几乎在我写的每一堂课上。
【讨论】：
提供足够覆盖率的良好单元测试可以让你晚上睡得更好。
如果您使用断言，您可以发现单元测试遗漏的潜在错误（有时可能不够好），并且您可以在晚上睡得甚至更好。
【讨论】：
它节省了我的时间，因为当我运行代码 TDD 时，它通常只适用于集成时间，因此无需花费大量时间进行调试。
这也让我有信心与其他声称我创建的 API 存在错误的开发人员进行对话。
【讨论】：
当您进行一些临界质量的测试时，一个很好的副作用通常是，如果您要引入一个错误，它可能会使某些测试失败，即使这些测试不是直接针对新的, 你写的代码有问题。
因此，您将在提交之前收到有关您即将提交的错误的警告，然后您可以针对它编写测试并立即修复它。
（当然，只有当您的测试不是“只是”非常狭窄的仅测试一件事的测试时，这才是正确的，但我认为这种情况更多见。）
【讨论】：