写可测试的代码

写可测试的代码

任何一个软件都是可以测试。在某种意义上，用户的使用过程也就是一个软件测试的过程。可是这并不是我们今天要讲的可测试性。我们讲的可测试性指的是代码的可测试性，通俗点儿说就是是一串代码里包含的逻辑是不是可以被单元测试所覆盖。在这篇文章里我会从单元测试的基本概念开始引伸到如何写单元测试，如何写可单元测试的代码。文章里所有的例子都是C#写的，一来它是我职业生涯的主力语言。二来C#广为人知，相信对广大职业的或是业余的程序员来说读懂C#的代码不会是什么特别困难的事情。实际上我描述的方法和概念并不会局限于C#或是.Net框架。它们应该可以应用在其他平台，如Java的开发上。

值得一提的是在这篇文章里，我引用了不少参考文献。他们大体上都有比较权威的来源，或节选于知名网站如MSDN，或出至名家之手。这些参考文献都是很有意思的技术文章，都可以轻易在互联网上面找到，绝对值得一读。

单元测试是啥？

维基百科里对单元测试有一段及其拗口的定义，我试着翻译一下:

“计算机程序里，单元测试是一个方法，一个可以配合可控的数据，使用流程或操作流程检测源代码，一个或多个软件模块的独立单元是否满足使用需求的方法”

英文好的朋友可以看看原文，看看会不会有更好更深入的了解：

“In computer programming, unit testing is a method by which individual units of source code, sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures are tested to determine if they are fit for use”

一边翻译一边写，一边写一边读，舌头都要打结了。相比之下还是百度比较人性，它说:

“单元测试是对最小可测试单元进行的检查和验证”

MSDN的解释对单元测试的方法做了补充说明:

“单元测试的目的就是从应用程序（application）抽取出最小的一块可测试的软件（software），把它与其他的代码分隔开来，然后判断它的行为是不是符合预期”

单元测试必须是独立的，无牵无挂的，所以我们得想办法把要测试的软件单元和其他代码分隔开来。罗一（Roy Osherove）在他的书《单元测试的艺术（The Art of Unit Testing）》里补充了单元测试另一个非常重要的属性：它得是自动的。

一个列子

自Visual Studio 2008开始，单元测试开始成为一个标准模版。创建单元测试的过程变得超级简单。这也间接地说明了单元测试在商业开发中的重要地位。微软MSDN上有一个详细的指导《Walkthrough: Creating and Running Unit Tests for Managed Code》，一步一步地帮助你创建单元测试项目。如果你从来没有接触过单元测试，这是一个很好的开始。在这篇文章中，微软举了一个很有意思的例子（码一），值得我们细细分析。

[TestMethod]
public void Debit_WithValidAmount_UpdatesBalance()
{     
   // arrange     
   double beginningBalance = 11.99;     
   double debitAmount = 4.55;     
   double expected = 7.44;     

   BankAccount account =new BankAccount("Mr. Bryan Walton", beginningBalance);      

   // act     
   account.Debit(debitAmount);      

   // assert     
   double actual = account.Balance;     

   Assert.AreEqual(expected, actual, 0.001,"Account not debited correctly");
}

码一

这个测试说的是一个人在银行账户里有11块9毛9时，他取了4块5毛5后账户里还应该有7块4毛4。这是一个典型的情景测试：我们假设了一个情景后测试逻辑运行的结果是否符合我们的预期。 眼尖的朋友或许已经注意到了，这个单元测试被分为个大块，Arrange，Act和Assert。引用这三块的第一个字母，我们可以说这个测试是AAA风格的测试。