不做单元测试的6大借口
看到了一篇不错的关于单元测试的文章，于是就机翻加改写了一下。作者的观点是适当的，不过稍微欠缺了些数据。原文地址：https://betterprogramming.pub/why-dont-we-do-unit-testing-e0bb55a38aa2
我开始打算写一篇关于单元测试及其背后的哲学和过程的文章。 我想谈谈完成对项目的一组更改并能够部署它们所带来的满足感，因为数百个单元测试正在通过，并且在生产中出现问题的可能性很小。 然后我意识到我参与过的大多数项目（在计算行业的长期职业生涯中）都没有使用任何类型的单元测试。 因此，我认为检查未使用单元测试的各种原因以及对这些项目的影响可能会有所帮助。
没有测试工具
当我在 80 年代开始以编程为生时，这是一个很好的借口。在 pascal 中编写航空电子代码，我们确实编写了测试，但几乎不得不推出我们自己的测试框架。这里没有 fakes、mocks 或 DI。 但是，如果您今天使用 Visual Studio 在 .Net/C# 中编写代码，则没有理由不测试任何重要代码。 VS Code 有一个内置的测试运行器，其他测试运行器也可用。fake 和 mock 框架被广泛使用，另外还有非常优秀的 CI/CD 支持，可以让你在构建过程中自动化的运行单元测试。
后面作者又列举了一些例子来证明一个观点：就是测试工具实际上是持续进化的，而且现在已经很强大了，因此他的核心观点应该是在如今这个年代，单元测试工具其实不应该是匮乏的，大家应该有不少的选择。
我们没有时间做测试
客户希望我们现在发货。写一些代码就行了。先搞出来吧，没有时间学习有关单元测试的象牙塔软件工程学士学位！ 你多久听说过一次？ 这种方法通常似乎在最初几周有效。然后，当您陷入莫名其妙的错误和副作用的泥潭时，生产力就会下降。加倍努力，开夜车，让更多的人进行手动测试！ 不必如此。我会说你没有时间不做测试。
看看上面的图表。橙色线显示“没有做单元测试”项目。 起初，我们可以通过不进行任何测试来节省时间。 随着越来越多的功能被实现，（手动）回归测试的负担呈指数级增长。添加的每个新功能都会带来额外的回归测试负担。 很快，您的项目将不得不在质量、成本和实现每个新功能所需的时间之间做出妥协。 所以是的，最初编写一个好的单元测试可能比手工测试你的功能要长两到三倍。但是经过两三个循环的回归测试，你就会领先——而且只会变得更好。
我们发现写单元测试好难
编写测试很难，这是绝对正确的。 编写好的测试更难。但不写测试会让你的生活更加艰难（或者你真的喜欢手动测试你的前任 5 年前写的代码？？？） 如果您的开发人员不知道如何编写好的测试，那么他们可能还不是好的开发人员（目前）。 但是他们可以学习。 写测试用例是一个不断进度熟能生巧的过程， 你做的越多，它就会变得越快越容易。 让最好的开发人员编写“模范”测试。 这些可以被经验不足的开发人员用作模板来创建他们自己的测试。 创建测试基类。 我经常这样做是为了封装经常重用的功能并简化单个测试用例。
单元测试是白费力气！
当我花时间编写单元测试时，我从不认为这是浪费时间。 如果我编写代码并手动测试它，我认为这是浪费精力。 在一系列手动测试结束时我会得到什么？ 代码在我做手动测试时候是没问题可以正常工作的，但如果我更改代码，我将不得不重复这些测试（或者更有可能不打扰……） 如果我创建了自动化测试，那么我就有了一个测试套件，我可以随时重新运行这些测试，以验证代码是否仍然按照我编写时预期的方式工作。 更重要的是，如果我离开并且一位同事接管了这段代码，他们就会继承这个祖传的测试套件，他们可以使用这些测试来验证他们的更改没有破坏它，并且代码仍然以我预期的方式工作。 手动测试是浪费精力——手动测试的剩余价值为零（并且通常没有记录，因此不可重复）。 自动化测试可以在未来几年内使用，以证明您的软件仍然按预期工作。