单元测试训练的好单元测试故事

Question

我必须建议在我的公司进行单元测试方面的培训。

我想展示一个惊人的，真实的例子，一个意想不到的回归没有捕捉到(当然)，但可以通过单元测试检测。

更像是一个看似有效的改变，它实际上会导致程序的另一部分出现倒退。

你会分享你的单元测试史诗般的胜利故事吗？

(目标语言是C++，网络分布式应用程序，但是任何好的例子都可以)

Answer 1

就我个人而言，我更看重单元测试在创建阶段的重要性，更重要的是它们能够迫使开发人员考虑他们编写的代码，并验证他们认为代码的行为。

当一个历史单元测试中断时，根据我的经验，这通常是由于预期的功能或设计更改，并且单元测试必须重写以反映新代码。虽然很少(每20人中就有1人)很快就发现了错误，但强迫开发人员证明他们的新代码的行为确实为代码基础增加了更多的价值。

Answer 2

当您必须创建可重用库时，单元测试的价值可以最清楚地理解，特别是当那些库是通用的，只有很少或根本不依赖于系统的其他部分时。

想一想数学库(例如，用于向量或矩阵操作、图或图形计算)。这些东西通常都是好的单元测试性，而且应该很清楚，一旦在十几个程序中使用了这样的库，在这个库中改变一些东西意味着您将不得不再次测试更多的程序，而如果您有一个覆盖范围很高的单元测试套件，则相反。

还有一些很好的布雷特·L·舒切特(BrettL.Schuchert)的视频，显示了实时的TDD编码，比如这是给C++的或这一张是Java的，也许你会发现它们很有帮助。

Answer 3

听起来你想在你的公司里“销售”单元测试。(对你很好！)

我会冒着被讨厌的危险，但听起来你自己可能不会100%清楚写单元测试的所有好处。正如其他答案所指出的，除了捕获编译器没有捕获的bug之外，单元测试非常有用(有时甚至是必要的)的原因很多。

我建议熟悉所有的好处，并相应地设计我的演示。

下面是一些我会讨论/演示的快速事项(不按任何特殊顺序)：

快速验证代码单元可以工作，而不必在预期的环境中实际运行它。当构建项目需要5分钟，部署项目需要10分钟，在代码实际运行以验证“工作”时，这一点非常关键。

验证在其预期环境中将非常难以测试的代码。我们编写的代码中有很大一部分是处理只有在某些奇怪情况下才会发生的错误条件或条件。这些情况在现实生活中很难再现，因此需要特别注意测试。

验证“库”代码。如果您正在编写其他人使用的代码，那么您唯一的验证方法就是编写另一个消耗和驱动它的“项目”。单元测试让你对你的代码工作很有信心，而不必使用驱动你的代码的项目来测试它，或者自己编写一个“测试”应用程序。

TDD。测试驱动开发是一种相当新的单元测试思维方式。使用TDD时，开发人员首先编写测试，然后编写代码。TDD可以通过只编写满足通过测试的代码来改进代码。关于这个问题有很多争论，我在某些情况下非常成功地使用了它，但在另一些情况下却没有那么成功(与上下文有关的IMHO)。

测试记录您的代码。很多时候，测试是关于代码应该如何运行的最新文档。为了了解如何使用类/方法，您需要找多少次已经存在的代码块来练习类/方法？单元测试给你的就是这个。

密码破坏。是的，单元测试确实会捕获bug。然而，我发现它们在开发过程中最常捕获bug。我编写代码，然后转身编写测试，这是我捕获大多数bug的阶段。

我相信这里还有更多的内容要提，所以你应该在培训前做更多的研究。还有一件事。当单元测试“在很大程度上节省了时间”时，很难找到示例，因为它们在开发过程中捕捉到了big，而且在大多数情况下都是非常安静的。只有在你写了一段时间才能真正了解它们的好处时，你才能看到它们是如何(每天)节省下来的。

我会把它们比作运动。如果每天运动能使人免于癌症或心脏病发作，就很难找到这样的情况。但你确实知道，健康长寿是必要的。