Day 2-什麽是单元测试及何谓优秀的单元测试？ (基础-1)

最初的单元测试传统定义

在 Roy Osherove 撰写的单元测试的艺术中，1970 年代就已经有单元测试的概念了。并且随着时代的推移，对於单元测试也循序渐进的完善其定义。而本书给出最初的定义如下：

一个单元测试就是一段程序码（通常是一个方法），这段程序呼叫了另一段程序码。然而验证某些假设的正确性。如果这些假设是错误的，单元测试就会失败。一个单元可以是一个方法或函数。

逐步更具体定义的单元测试

第一时间观看其定义，会觉得满合理的，毕竟单元测试的用意就是为了验证其方法是否符合预期结果。然而，在仔细观察其定义会发现，其定义提到的一段程序码（通常是一个方法），这段程序呼叫了另一段程序码，这段程序码指的是一个工作单元，可能包山包海，可能验证了一个方法；但也有可能验证多个类别与函数。

换言之，可能会随着不同的开发者，定义出不一致的单元测试风格（ A 开发者写出一只工作单元验证其方法的其中一个情境， B 开发者则写出一只工作单元验证功能所需要考量的情况）。

图 1、A 测试员的测试单元逻辑

图 2、B 测试员的测试单元逻辑

也因此，本书逐步修正了最初的单元测试定义：

一个单元测试是一段程序呼叫一个工作单元，并验证工作单元的一个具体最终结果。如果对这个最终结果的假设是错误的，那单元测试就失败了。一个单元测试的范围，可以小到一个方法，大到多个类别。

走向成为优秀的单元测试

根据上述的定义，单元测试有了更完善的解释；然而，随着软件系统开发的开发周期缩短且复杂度提升，往往许多时候以往开发的单元测试成为了可怕的技术成本之一。比方说，开发一只新功能所花费的时间为一小时，但要验证这新功能的单元测试也同样要花费一小时，甚至更长，身为开发商大多会选择忽略以缩短短期内的开发时程，进而导致牺牲测试带来的长期维护效益。Roy Osherove 在本书提出优秀的单元测试应具备以下这些特点：

• 自动化，且可被重复执行；
• 容易被实作；
• 撰写後的第二天应还具有其意义；
• 任何人按执行皆可做测试；
• 执行速度快；
• 能完全掌控且被测试的单元；
• 完全被隔离的（执行时独立於其他测试）；
• 执行失败，应该能清楚的呈现预期结果为何？详述其发生的问题原因。

从以上观点，大致上可分成几个方向：

1. 是否容易且可自动化被执行。举反例来说，若单元测试会随着 NUnit 套件版本不同 (如 ExpectedExcetption 特性) 而无法执行，则这不是好的单元测试。
2. 执行速度是否可在几分钟跑完所有测试。大多开发期间，为了确认是否修改功能而影响以往的功能清单，单元测试变成了很好的参考机制，但若测试时间过长则会渐渐影响开发人员执行测试的频率，最不理想情况则可能忽略测试。
3. 可否快速开发基本的单元测试。如前一段提到，若开发单元测试的难度比开发功能困难，则会连带影响开发测试的品质；其中，设计模式（Design Pattern）会直接影响单元测试难易度，要写好的单元测试，通常会依据介面（Interface）的设计决定测试单元如何在适当的时机点介入功能并检测需要验证的功能（若有兴趣会在单元测试-核心技术系列介绍）。

因此，总结以上叙述，Roy Osherove 在单元测试的艺术最终给出的单元测试定义如下：

一个单元测试是一段自动化的程序码，这段程序会呼叫被测试的工作单元，之後对这个单元的单一最终结果的某些假设或期望进行验证。单元测试几乎都是使用单元测试框架进行撰写的。撰写单元测试很容易，执行起来快速。单元测试可靠、易读、并且很容易维护。只要产品程序码不发生变化，单元测试的执行结果是稳定一致的。

接下来，明天会提起何时该用单元测试（换种说法，就是要判别何时不该用单元测试），会提起常跟单元测试一起讨论的整合测试、以及网页开发会提到的端点测试等做比较。