Day 3-何时用单元测试？在这之前，要先厘清除了单元测试以外的测试 (基础-2)

单元测试的好朋友—整合测试 (Integration Test)

在昨天 Day 2-什麽是单元测试及何谓优秀的单元测试？ (基础-1) 曾提到早期的测试开发，可能会因为开发者风格的不同，导致测试单元可大可小；换一种说法，若今天这次测试单元检测由复数个逻辑组成的功能例如开发系统时，先从资料库取得资料後进行商业逻辑处理，再进行资料重组等，则大大地增加测试的复杂性。举例来说，撰写测试流程中可能会因为检测复数个检查点如资料库连线、原生 SQL 或 ORM 取得的资料是否正确、演算法的流程是否有误、模拟资料结构重组後是否符合预期等，而可能产生多个失败的可能性。

此外，上述流程或许多其他的系统开法，其商业逻辑通常会搭配第三方套件资料结构或功能，会使得原始码无法完全掌控，违背了单元测试的定义。然而，对於系统的稳定性，还是需要验证模组与模组之间的逻辑关系（由如上述的检验流程），又或是透过第三方套件验证一些行为 (Behavior) 是否执行正常（例如：利用 NUnit3 + Selenium 验证网页的 UI 元件执行情况或 NUnit3 + EntityFramework 创造测试用的资料库与资料表进行 SQL 相关功能的验证等等）。

因此，Roy Osherove 在单元测试的艺术中定义了整合测试：

整合测试是对一个工作单元进行测试，而这个测试对被测试的单元并没有完全的控制，而是使用该单元的一个或多个真实依赖的相依物件，例如时间、网路、资料库、执行绪、或乱数产生器等等。

综合单元测试与整合测试的描述，两者之间最大的不同在於，单元测试的测试流程需引用本身内建的程序码功能（已达到完全控制，不会有黑盒子的状况）；而整合测试则是可利用第三方套件验证较复杂的行为且可针对较流程繁琐的系统进行整合性验证。

网站测试常用的概念—端对端测试 (E2E Test)

另一种常见的验证方式，是利用使用端对系统端进行测试。常见的例子是网站系统上线时，模拟使用者的行为对网站进行互动，并验证其结果是否符合预期行为。此部分的行爲是最为复杂的，常见的例子是早期网站开发时，版面的状况会随着浏览器的不同导致不一样的排版，针对排版自动化的测试是极其复杂的事情，因此常见的手法为开发完的系统上线後，由开发团队的 PG, SA, PM 等人一同人工观阅其正确性。

但後来针对端对端测试，依然还是有采取半自动化甚至可达到全自动化的测试，比如 Google 针对发展的 Angular Material UI 元件库还是提供了可自动化且完整的 E2E 测试，透过自动化截图并匹配图片来比对 UI 误差是否大於 1px 的手法，提供该资讯的文章来源可参阅 Will 保哥的文章-次搞懂单元测试、整合测试、端对端测试之间的差异又或是直接观阅 Google 提供的说明会。而现在大多前端的套件或工具都有针对 E2E 测试提供各种 APIs，比如 Postman、Vue.js、React.js 或 Angular.js。

单元测试的使用时机

相信除了整合测试、端对端测试，还有许多其他的测试方式；但因为篇幅关系在此就先不探讨，所以总结单元测试是在撰写套件时，验证其行为是否符合预期、整合测试是在系统模组与模组之间介接的时候，验证其相互行为是否正常；而端对端测试则是在验证系统（文章以网站为例）运行是否正常。以下的图做个这三个测试之间关系的总结：

如果想了解更细，可参考 Lawrence Tan 在 Medium 写的文章——Unit Tests, UI Tests, Integration Tests & End-To-End Tests 在 In Summary 阶段提供了数张图片，很清晰的诠释了这几种测试之间的关系该文章提供了单元测试、整合测试与端对端测试的相对应关系。

查阅单元测试意外发现的范例与心得

此外，在查阅整合测试的相关资料时，发现 C# 论坛中，已经有人在探讨如何用单元测试或整合测试的观点来验证 Web APIs 的功能是否正常 (RESTful Day #7)。会做为在此三十天当中，单元测试-情境及应用部分的主题参考，若有兴趣者可先翻阅该网站，又或是等我下半月的文章。

最後，花了三天的时间介绍了＝＝单元测试的基本概念（很多都是在网路上常介绍的内容，透过这三天算是做个整理），明天开始会开始接触程序码（C#、NUnit 3）及环境设定（终於要开始写程序码了 XDDD）。