单元测试培训系列: （1）单元测试的概念和必要性

说到它，大多数学生应该知道或听说过它. 也许许多学生认为他们已经写了它，甚至认为单元测试非常简单. 什么训练好？其实，这件事确实没有想象中那么简单！我基本上可以说，如果您还没有深入研究单元测试，并且您不知道Mock对象是什么，那么您之前编写的单元测试可能根本就不是单元测试.

什么是单元测试？

实际上，用一两句话很难说清楚这个问题. 首先借用百科全书的定义:

单元测试是在软件开发过程中执行的最低级别的测试活动. 在单元测试活动中，将独立于程序的各个部分来测试独立的软件单元.

从上面的定义中，我们可以看到两个词提取为两个非常关键的词: 最小粒度，隔离性

●单元测试是最小的测试单元，必须是可信任且可重复的.

●如果可以轻松地将测试范围扩展到其他类或相同类型的其他方法，则它不再是最小的单元，而是单元测试！

例如:

在类A的方法CallMethod中调用类B的方法DoMethod. 如果在编写测试时未隔离类B的DoMethod，则在对CallMethod方法进行单元测试时实际上将实现DoMethod方法. 测试方法不能算作单元测试. （如何隔离将在后面详细说明）

单元测试的目的是什么？

有人曾经给我一个非常简单的代码片段: 一个方法，它仅调用其他几个方法，甚至没有任何返回值，然后问我这段代码对编写单元测试是否有价值？ ！这是浪费能源！ ！

publicclassClassA

{

publicvoidCallMethod（）

{

DoSomethingForYou（）;

DoSomethingForThem（）;

DoSomethingForMe（）;

}

}

实际上，引起这个问题的主要原因有两个: 无法理解单元测试的目的和此代码的可测试性低. （可测试性及其改进方法将在后面的章节中介绍）

单元测试的目的是确保程序的逻辑按预期执行，而不是验证其​​是否满足客户的需求！单元测试用于建立坚实的保证，以确保将来的修改不会破坏代码.

您感到失望吗？不使用单元测试来验证代码是否符合要求.

实际上，单元测试是一种类型，需要开发人员来完成. 最好由开发人员编写单元测试代码，因为代码的编写者最熟悉代码的目的. 编写可验证是否达到目标的单元测试代码.

不能使用单元测试来替代其他测试方法，但是它确实可以有效地帮助开发人员在实践中检查代码，然后发现一些潜在的错误. 但这只是额外的好处. 如果您不使用TDD作为测试优先的开发方法，那么单元测试的根本目的就是不使用它，并且不能验证当前代码是否有错误！

据说单元测试最好由开发人员自己编写，并用于验证代码是否满足开发人员的预期开发要求. 这里可能有一个问题. 由于开发人员本人已经确切知道自己想要什么，因此直接运行代码并运行一次. 通过断点调试验证不是很容易吗？然后通过编写代码的形式（甚至比此函数本身的开发更多的代码）来验证此方法是否满足编写的目的，这不是一个愚蠢，愚蠢而又累人的方法吗？

也许可以通过每个人经常遇到的实际场景来更好地解释:

在项目开始时，项目经理将需求分解为几个模块，并将其分发给不同的开发人员以完成. 这样，每个人可能只熟悉其代码的那部分. 当项目的某个阶段完成并投入使用时，一些开发人员可能会离开该项目进入另一个新项目，从而使个人人员继续维护；或项目下一阶段的大量新人员不熟悉当前项目；当然，最常见的是，在BUG修改阶段，不可能完全修复产生BUG的任何人.

【福利】填写问卷并发送选择的测试包+界面测试课程！为测试行业做些事！

这时会出现一种常见情况: 由于不熟悉当前代码必须满足的各种目的，因此在修改模块或BUG时，原始的正确功能也会受到影响！更可怕的是，没有人知道这个错误已经出现，等待测试人员重新发现它.

因此，项目经理会发现，每次进行代码修改时，无论是重构，新功能修改还是BUG修改，都无法知道当前代码的健壮性. 以前写的东西仍然可以正确使用吗？

但是单元测试的目的，如果在该项目开始时编写了单元测试，那么我们可以通过一个方便的自动化单元测试框架来运行所有单元测试，然后检查修改之前单元测试所涵盖的所有代码是否仍然正常运行（满足先前编写的单元测试期望，如果验证通过，则认为原始代码不受影响）

从上面我们可以看到，尽管单元测试增加了大量的开发工作，但是对于长期的持续改进和维护项目，单元测试是降低总体成本的有效手段. 可以及时发现，修改代码后，代码所需的原始功能是否仍然可以正确满足.

但是这里存在一个严重的缺陷: 单元测试无法检测某个方法是否已被修改以影响其他方法，而只能检测到修改后的方法本身的原始目的是否受到影响（将在下面的解释中进行描述）. 详细介绍与集成测试的区别）

因此，我个人认为，最适合单元测试的方案是基于TDD开发的. 如果需求发生变化，则方法会被修改，并且在大多数情况下，单元测试代码也会被修改，因为期望也发生了变化，此时，无法检测到对其他代码的影响，并且单元测试实际上是目前没有意义.

单元测试和集成测试有什么区别？

大多数人无法区分集成测试和单元测试，甚至很一直理解的单元测试也只能被视为集成测试，但是两者的概念完全不同.

单元测试的目的是每个独立的方法，并尽可能地隔离该方法和其他方法以及其他外部依赖项；

基层测试的测试对象是单元测试检测到的方法到方法的调用关系，以及调用执行过程是否符合预期.

●测试项目的一部分或全部，可以跨越不同的类别和方法，并且可以直接访问外部资源. 例如: 文件I / O，操作，网络连接...

●通常，在执行集成测试之前，您需要配置配置测试所需的环境. 测试完成后，通常会清除测试生成的剩余数据，以方便进行下一个测试或避免影响其他集成测试的结果.

○ClassInitialize属性

○ClassCleanup属性

○TestInitialize属性

○TestCleanup属性

这些属性通常在集成测试中使用，而不能出现在单元测试中.

单元测试的三个基本要素（可信赖性/可维护性/可读性）

1. 相信您的测试代码结果

1）您可以信任您的测试结果吗？

2）当它通过时，我们相信被测代码必须能够正常工作.

3）失败时，必须证明被测代码是错误的.

【福利】填写问卷并发送选择的测试包+界面测试课程！为测试行业做些事！

4）如果您继续对测试结果失去信心，那么您将不会继续编写单元测试. 是的

5）许对单元测试和集成测试之间的差异感到困惑，以至于他们感到编写的单元测试太弱了，无法相信测试结果.

6）如果由于某种原因测试失败，那么直接更改代码或直接更改测试代码不是一件好事. 您的主要目的是能够找出测试失败的主要原因，而不仅仅是查看错误. 这样，您就可以信任您的测试程序.

2. 测试代码的可维护性

1）您可以继续维护测试程序吗？

2）如何有效降低维护测试程序的成本？

PS: 通过一些可测试的设计模式可以有效地提高可维护性. 例如: 存储库模式，服务模式...

3. 测试代码的可读性

1）测试程序的名称易于理解吗？

2）测试失败时单元测试的目的，可以从测试失败的测试方法（TestMethod）中清楚地看到实际失败的原因吗？

3）当读取测试数据的人员不理解您的测试时，人们将不会执行或维护这些测试，并且随着时间的推移它们会变得更糟.

测试驱动开发和单元测试

在本文末尾写的文章中，我始终认为单元测试实际上是TDD开发模型所固有的. 在此开发模型中使用单元测试非常顺利:

1. 根据软件需求文档拆卸软件功能并设计功能模块分区；

2. 根据所需的功能模块设计单元测试方案用例，因为此时您可以清楚地知道可以提供什么样的数据以及需要实现什么样的功能. ;

3. 编写单元测试代码. 这时，您可以集中精力检查此方法是否满足设计要求. 这时，甚至根本还没有开发实际的代码，并且可以在此处完全获取.NET 4.0的Dynamic关键字. 播放: 调用尚不存在但不会导致编译失败的方法.

4. 在编写单元测试的过程中，可以预期，如果此方法需要调用其他一些类或方法来进行支持，则可以通过编写Mock Object来模拟它，该对象也不需要实现真正的代码，而只需实现基本的Code框架或界面就足够了.

5. 在为此方法编写了单元测试代码之后，就可以开始编写实际的代码实现了，因为为了满足Testability的需要，该代码已经基于依赖项反转模式，因此无需担心其他需求被调用的类或方法已经实现或正确实现. 编写完此方法的实现后，可以通过运行先前的单元测试来接受它.

如您所见，如果您以这种方式进行开发，首先，代码的耦合度非常低，其次，代码的质量也很高，最后，由于代码之间的耦合度低，开发将被减少. 代码在此过程中，相互影响彼此进度的可能性受到限制. 跟踪错误还有一个优势: 很容易找出错误是否正在扩散.

相反，重构旧版系统使其可测试，然后编写单元测试实际上并不是一个小工作量，并且实际收益不会特别大.

单元测试的基本概念和价值已基本完成. 下一篇文章将开始介绍Visual Studio 2010中的单元测试工具和环境.

相关链接:

单元测试培训系列: （2）可测试性和重构

【福利】填写问卷并发送选择的测试包+界面测试课程！为测试行业做些事！

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-216856-1.html