单元测试如何让您的生活更美好？

Question

好吧，老实说，我的生活中可能没有写过10多个单元测试。

我正在开始一个新项目，并且作为唯一的程序员意味着我应该害怕......非常害怕。

我可以伪保证我的软件工作的想法带来一种快乐感。

当然，我会错过很多我应该测试过的案例，但随着时间的推移，这将是我学习的地方。

单位测试可以帮助我在晚上睡得更好，这对我的健康有益。

我的代码会失败，但至少我会更好地了解它。

如果你的团队其他成员没有加入潮流，那么单元测试如何让你的生活变得更好（或拥有它？）？

Answer 1

单元测试对我的项目的最大价值是置信度。有了这种信心，就可以更容易地添加一开始就没有计划的新功能，并将代码分开来改变一些东西或转过来。

通过测试我知道我（或其他任何人！）没有破坏已经有效的东西。

在没有测试的情况下，当您进行重大更改并在下一分钟将其部署到生产环境中时，您就会非常勇敢（或愚蠢）。

Answer 2

好吧，由于没有其他人加入到扮演魔鬼的拥护者的角色，我会做的。

自动单元测试可以为某些项目带来好处，但也可能存在以下许多问题：

• 它吸收了大量的工程资源。
• 从等式中删除环境和设置问题可能需要很多工时。
• 某些项目类型的投资回报率较低，尤其是GUI。
• 它不会捕获很多错误，因为除了最琐碎的程序之外，不可能评估所有执行路径。
• 它不会捕获集成错误。
• 它不会捕获更广泛的系统级错误，例如跨多个单元执行的功能，或性能等非功能区域。
• 测试覆盖率和覆盖门可能会成为越来越无用的口头禅
• 它需要一个可持续的流程来确保立即审查和解决测试用例失败。否则，应用程序将与单元测试套件不同步。
• 它有很大的机会成本 - 还有其他活动，如代码审查，具有同样好的甚至更好的投资回报率。
• 它可能涉及重大的文化变革。

因此，开发人员不应采用教条（是或否）方法进行单元测试，而是对每个项目进行ROI计算。

Answer 3

通过单元测试，我减少了在测试阶段报告的“愚蠢错误”。它也让我对我的代码更有信心。

Answer 4

正如Elie所说，单元测试是很早就清除“愚蠢”或简单错误的好方法。 对我来说，它改变了我对代码的思考方式;使我的代码可测试使它不那么脆弱和更灵活（例如，依赖注入/控制反转对我来说非常自然，因为它是我为测试目的所做的事情。）

我个人从一个完整的测试套件中获得的最大好处是，即使在我写完这些代码的几个月之后，也可以自信地更改复杂的代码而不必担心意外破坏。

我还没有，但在编写它们时有一些纪律，单元测试也是记录代码的好方法。

Answer 5

自从我在大学的第二个*项目（早在1988年）以来，我一直是TDD（开发人员）。我不知道这个词是否在使用中。

最好的事情是改变事物的能力，并且很快检查你没有破坏任何其他东西。简单的回归测试。

它们也是对象/方法用法的良好文档。

*这直接是因为第一个项目的进展......

Answer 6

单元测试给你的最重要的事情就是对你的代码充满信心。你知道东西在一定的质量水平上起作用，而且你知道你可以进入并改变或重写某些东西而不会让你的东西在你不期望的地方失败。验证只是一个测试。

Answer 7

现在我开始尝试使用功能，组件或功能来测试我的代码，我知道我什么时候完成。因此，我可以准确报告进度。

我知道这不是无错误的代码，但它的功能足以集成，构建并交付给QA。我自信他们将能够开始测试而不会受到分段错误或任何其他愚蠢问题的阻碍。

我还准备好了环境，以便我可以快速编写一个新的测试来重现任何问题，并且我会有一个安全网来检测一面修改或修复代码时的效果和回归。

Answer 8

对我来说，不仅仅是单元测试改变了我的生活，而是测试驱动开发（TDD）。我把它比作我在博文中的宗教体验（无耻，我知道）My Year with TDD。

进入测试对我来说是一次改变职业生涯的经历。我写了更少的错误，我写了更多可读的代码，我编写了更多有凝聚力的代码，我知道什么时候（通常）有些东西被破坏等等。我应该把它归功于测试驱动开发。

尝试一下，你喜欢它：）

Answer 9

当您开始调试时，单元测试非常有用。如果您的测试失败，那么您几乎可以立即知道错误的位置。如果它们全部运行，那么你知道错误不在哪里（大部分时间）。

单元测试有助于的另一个领域：迁移软件。我发现准备将单元测试迁移到Python 3的Python代码比没有单元测试的代码要容易得多。

  

当然，我会错过很多我应该测试过的案例，但随着时间的推移，这将是我学习的地方。

这是测试驱动开发真正发挥作用的地方。您不必担心进行适当的测试，因为事先会回答您的问题。

当然，为了确保我们在同一页面上，“测试驱动开发”意味着编写测试的过程，验证测试失败，然后编写代码。

Answer 10

将单元测试与TDD结合使用，为我提供了完成手头任务的动力和动力。如果没有编写测试，修复测试，编写测试，修复测试的小进展，我就会变得没有动力。

Answer 11

我必须说我认为VS 2010中的改进，例如Ctrl + Enter（我认为就是这样）可以让你在编写测试时快速存根一个类的接口（第一个）让我更轻松。

Answer 12

单元测试不是灵丹妙药。但它确实有好处，而且非常令人满意。

我发现这意味着我的代码会更早地执行，因为在我编写单元测试之前，在应用程序中有足够的功能尝试之前需要进行大量的编码。

当我来重构时，我也非常感谢我的单元测试套件。我刚才重写了一个完整的日期处理模块，如果没有回归测试，我就没有办法有信心做到这一点。

Answer 13

单元测试的优势是多方面的。为了更具体地说明它如何让我的生活变得更好，我认为它增加了对变化的信心，并让我有可能在以后更快地改变代码。从长远来看，它会增加我的生命。

当然，我可以在短时间内说出它有点痛苦，因为它需要更多的时间，但是当你进行这些测试时自动验证自己会很快忘记它。

Answer 14

不能代表所有人，但我开始编写测试，因为我在开发系统时编写的测试对我很有帮助。

我还发现，在使用新的代码库时，测试是验证假设的好方法。

Answer 15

我是单元测试的忠实粉丝，虽然我的测试现在还没有提供完整的报道...主要是因为我在网站上工作，我的大部分代码只是抓取数据库中的数据，操纵它，并吐出来。操作代码通常经过充分测试，但测试数据库代码真的很痛苦。

话虽这么说，我可以指出一个案例，单元测试为我节省了数周的工作......

我曾经在一个小项目（4-6个开发者）工作了一段时间，经过几个月的工作，我们已经接近完成状态。在这一点上，负责产品的人决定，不是在GMT中存储日期（并使用它们生成报告），而是在EST中想要一切。鉴于该产品是为处理大量数据/日志而生成的，并根据时间框架生成有关该数据的信息，这是一个相当重大的变化。

在接下来的几天里，开发团队进入并改变了所有处理EST时间戳的方法。如果我们没有进行如此广泛的自动化测试，我们需要花费数周的时间才能完成这些工作需要花费3天时间才能让我们满足激进的时间表。我们能够跳进代码并开始改变我们需要的东西;如果我们破坏某些东西，那么单位测试会让我们有勇气，因为我们知道系统会很快抱怨。到目前为止，我将这种经验作为一个例子，说明如何在自动化测试为您节省开支之前永远无法真正理解自动化测试的好处......而且它确实为我的团队做到了这一点。

Answer 16

我在java中做了很多工作，在Ruby中做了一年。

在Ruby中，我们使用了广泛的测试（TDD）。这是绝对必要的。您可以将几乎完整的垃圾写入Ruby文件，如果您没有达到特定的代码行，您将永远不会知道，因此您的测试需要接近100％的覆盖率。

在Java中，我从来不需要一个简单的简单成功路径测试 - 而且通常可以在代码运行后丢弃。它实际上是静态类型检查，强类型和使用强大的封装和参数检查等编码模式使这成为可能。实际上你可以非常接近地证明一个小类在没有测试的情况下不能被破坏（没有bug），并且在正确设计时，所有类都应该很小。

另一个兴趣点：在Ruby项目中，我们有一个重构器，它花了我们2天的实际代码工作（将主要模型类拆分为两个类）和2周的测试修复。

在某些时候，所有这些测试都有价格，它们仍然是你必须维护的代码。

也就是说，我发现TDD很有趣，也是开始工作的好方法，即使是在Java中也是如此，我也会重申，我总是至少会有一些成功的路径测试（即使它只是一个快速的主要方法）几乎我写的每一堂课都有。

Answer 17

它节省了我的时间，因为当我运行代码TDD时，它通常只适用于集成时间，因此无需花费痛苦的时间进行调试。

它还让我有信心与其他开发人员进行对话，声称我创建的API存在错误。

Answer 18

当你进行一些临界质量的测试时，一个好的副作用往往是，如果你要引入一个bug，它可能会使一些测试失败，即使测试不是直接针对新的，你正在写的错误代码。

因此，在您这样做之前，您将被提醒您将要提交的错误，然后您可以针对它编写测试并立即修复它。

（当然，只有当你的测试不是“仅仅”非常狭隘的测试一件事测试时，这当然是正确的，但我认为通常情况并非如此。）

Answer 19

提供足够覆盖率的良好单元测试可以让你在晚上睡得更好。

如果您使用断言，您可以找出单元测试遗漏的潜在错误（有时可能不够好），并且您可以在晚上更好地睡眠甚至。

Answer 20

我目前正在试图加入这个潮流。工作伙伴在编写一系列功能代码之前就已经在做了。我还在编写一个完整的程序，然后才开始运行它，更不用说单元测试它了：/

我肯定会到达那里。但是目前，通过花费90％的生命调试，我身体不好:(