单元测试的目的

在你开始学习任何新的技能或概念之前，我建议你先看看我的课程“快速学习任何东西的10个步骤”。

昨天有人提醒我，仍然有很多人还没有真正理解单元测试的目的。

最近5年左右发生了一个有趣的转变。

大约5年前，当我建议在创建代码时使用TDD或者只是做一些单元测试时，我会得到可怕的回应，许多开发人员和管理人员不明白为什么单元测试很重要，认为这只是额外的工作。

最近，当我听到人们谈论单元测试时，几乎每个人都同意单元测试是一个好主意，但不是因为他们理解为什么，而是因为现在编程界期待着单元测试。

没有理解的进步只是在一个随机的方向上前进。

回到基本点

单元测试根本不是测试。

单元测试，尤其是测试驱动开发，是一种设计或实现活动，而不是一种测试活动。

单元测试有两个主要好处，其中大部分价值都归第一个：

1. 引导您的设计实现松散耦合和良好充实。如果进行测试驱动开发，它会将您编写的代码限制为只需要的代码，并帮助您以小步的方式改进代码。

2. 为重构和代码的小改动提供快速自动回归。

我不是说这就是全部的价值，但这是最重要的两个。

单元测试强制您实际使用正在创建的类，如果类太大并且包含多个责任，则会对您进行惩罚。

通过这种痛苦，您可以将设计更改为更具内聚性和松散耦合性。

您可以考虑您的类可能面临的更多场景，并确定这些场景的行为，从而驱动类的设计和完整性。

完成后，您将得到一些自动化测试，这些测试不能确保系统正常工作，但可以确保功能不会更改。

实际上，在创建代码时，大部分的价值都是在创建单元测试的过程中产生的，这就是为什么在编写代码之后再回去编写单元测试是没有意义的主要原因之一。

有缺陷的思维

下面是一些不好的no no，它们表明您不了解单元测试：

• 您在编写代码之后编写单元测试，而不是在编写代码期间或之前。

• 您让其他人为您的代码编写单元测试。

• 您编写集成测试或系统测试并调用它们，仅仅因为它们直接调用代码中的方法。

• 您让QA编写单元测试，因为它们毕竟是测试。

单元测试有很多工作要写，如果你想用单元测试来覆盖整个系统，并有相当多的代码覆盖率，你所说的是大量的工作。

如果您没有获得单元测试的第一个主要价值，改进您的设计，那么编写单元测试就是在浪费大量的时间和金钱。

老实说，你认为把一堆你已经写过的代码或者其他人已经写过的代码交给每个人来编写单元测试会怎么样？

你认为仅仅通过添加单元测试而不改变代码就能神奇地改进代码吗？

也许你认为回归的价值如此之高，以至于可以证明这种成本是合理的？

我并不是说不要在遗留代码中添加单元测试，我是说当你在遗留代码中添加单元测试时，你最好从中获得你的价值，因为这是一项艰苦的工作，需要花费很多时间。

当您触及遗留代码时，重构该代码并使用单元测试来指导重构后的设计。

不要认为单元测试是神奇的。

单元测试就像一个指导方针，它可以帮助你把问题解决得更清楚。在你已经解决了问题之后，再给一个word-working项目添加指导方针是很可笑的。