前后端分离开发模式下后端质量的保证 —— 单元测试

概述

　　在今天， 前后端分离已经是首选的一个开发模式。这对于后端团队来说其实是一个好消息，减轻任务并且更专注。在测试方面，就更加依赖于单元测试对于API以及后端业务逻辑的较验。当然单元测试并非在前后端分离流行之后才有，它很早就存在，只是鲜有人重视且真的能够用好它。而在前后端分离开发模式下，特别是两者交付时间差别很大的情况时，后端可能需要更加地依赖于单元测试来保证代码的正确性。

　　本文主要围绕单元测试展开，从单元测试的基础概念说起，对比单元测试和集成测试，同时我们还会聊一聊单元测试与测试驱动开发的区别。在我们了解完单元测试的概念之后，我们会探讨一下什么样的单元测试算得上是好的单元测试，它们具备哪些特征，如何使用隔离框架来帮助我们对一些复杂的组件进行测试。最后一个内容也是本文想要阐述的重点： 单元测试是开发人员写的，那么开发人员在写自己的代码的时候，如何提高自己代码的可测试性？ 什么样的代码算的上是对单元测试友好的代码？ 带着这些问题，我们这就来开始我们的单元测试之旅。

什么是单元测试？

　　有人可能写过单元测试，但是却不知道为什么要写单元测试，有人知道为什么要写单元测试，但不确定如何写才是好的单元测试。但是对于“测试” 我们每个人都轻车熟路， 你看看下面的功能是否似曾相识？

单元测试与测试

　　测试种类分为很多种：单元测试、集成测试、系统测试、压力测试、负载测试、验收测试等等 ，我们今天不打算也不能进行系统性的介绍。作为开发人员，我们平常所说的“测试”。也就是说你代码写完了，老大问你测试通过了吗？你说过了，然后就可以Check in 代码了。这里的“测试”，实际上指的是不完整的功能测试。为什么说它不完整，是因为从专业测试的角度来讲，还需要定义规范的测试用例，用例写完之后还要开发和测试人员一起评审等等 。 而我们只是在脑海中预想了一下它应该如何工作的，应该给我什么结果等，然后运行一下，咦，还真是这样的，那我们的测试就算通过了。 会有多少Bug，就取决于我们这个预想有多细了，往往有时候我们只能想到很少一部份，这时候专业独立的测试人员就派上用场了。同时精通开发和测试的人是很有优势的，自己能够保证写出来的软件的质量，这也是现代敏捷开发团队所追求的，但是这样的人总是少之又少。

　　单元测试是通过把一个应用程序拆分成可测试的足够小的部分，然后把每一部分与其它所有功能隔离开，单独对这一部分进行测试。而这个“可测试的足够小的部分”就称之为“单元“，在C语言中一个单元可以是一个函数，在C#中单元测试可以是一个类。 如果所有的单元都能够像我们所预料的正常工作，那么把他们合并起来就能够保证至少不会出现很严重的错误。

单元测试与集成测试 

　　 为什么要把这两项拿出来对比，是因为这两项很容易混淆，一不小心你就可能把单元测试写成集成测试了，这也是为什么单元测试有时候看起来那么糟糕的主要原因。我们上面说单元测试是把每一个单元孤立出来，在测试的时候不能和任何其它的单元有任何联系，这是单元测试，反过来你一旦在你的测试代码中引入了另外一个单元，那你就要开始小心，你是不是已经开始写集成测试了。 当然有时候往往不是引入了其它的一些单元，有可能是一些组件，下面列出了一些单元测试和集成测试的主要特点，希望能够帮助大家区分单元测试与集成测试。

单元测试

• 可重复运行的

• 持续长期有效，并且返回一致的结果

• 在内存中运行，没有外部依赖组件（比如说真实的数据库，真实的文件存储等）

• 快速返回结果

• 一个测试方法只测试一个问题

集成测试

• 利用真实的外部依赖（采用真实的数据库，外部的Web Service，文件存储系统等）

• 在一个测试里面可能会多个问题（数据库正常确，配置，系统逻辑等）

• 可以在运行较长时间之后才返回测试结果

单元测试与测试驱动开发（TDD)

　　测试驱动开发其实我们用一个问题就可以解释清楚，那就是“你什么时候写单元测试？” 有人选择在开发的代码写完之后再写，这样我们的开发过程是： 理解需求-》编写代码-》针对代码结合需求写单元测试。后来大家发现，往往在写单元测试的时候发现自己有些需求没有理解清楚，或者这些需求原来设计的时候就没有考虑到，所以又重新改原来的代码。 于是有人就说，为什么我们不干脆反过来？ 先写单元测试，再写代码？  所以我们开发的过程就变成了这样：理解需求-》针对需求写单元测试 -》 编写代码让单元测试通过。 最开始是叫测试先行（TFD： Test First Development) ，后来就发展成我们熟知的"测试驱动开发"了。

　　测试驱动开发最大的好处是，让开发人员更好的理解需求，甚至是挖掘需求之后再进行开发。 当然，我们不可能一次性把所有的测试代码都写出来之后再写代码，这是一个重复迭代的过程：