Day 1-单元测试 (前言)

以往工作的经历，身边工程师对测试的认识

对於目前撰写程序的开发员来说，「测试」一词大多是不会感到陌生的。甚至很多人也可说出测试大致上的目的；然而，就我目前所接触的软件开发公司 （大多是专案公司） 中鲜少有导入测试的专案或产品，部分担任 PM 或 SA 工程师甚至曲解了测试的意义。

举个比较极端的例子，在以往的工作经验就曾遇过在一个系统专案报告上，听闻 PM 对业主解释系统契约书的内容，说明 QA （Quality Assurance） 就是：

> 针对各个审查系统的委员提出的 Question 并回答 Answer!

但此案例为比较极端的案例，相信大多工程师还是能答出 QA 的用意。

从 Freshman 到 Junior 工程师对测试开发的看法

许多撰写系统的工程师，对於测试是有初步的了解，但具体的内容是做什麽就比较少接触。比方说，撰写功能在最後选择回传资料或执行动作，对於测试开发工程师撰写测试的难易度就具有明显差异的难易度 （会牵涉是否需要导入假物件，且是否验证假物件的行为等等）。

此外，设计模式（Design Pattern） 的完整程度也会影响测试框架撰写的难易度，所以很常听到许多新人工程师对於 Legacy Code 的专案，说要撰写测试并重构功能；但而後不了了之的原因也是其对设计模式不了解或设计模式设计不良，增加了测试开发难度（题外话，在我刚进入软件产业，还是 Freshman 的时候，想说修改并扩充维护案就想说只要读 MICHAEL C. FEATHERS 撰写的 Working Effectively with Legacy Code，就可以轻松解决祖产，但後来被系统狠狠教训了）。

参加铁人赛的动机

会参加这次 30 天铁人赛的原因是在前阵子我所负责的一只系统上线，上线三个月後在一次偶然的机会，与一位使用者的闲聊才得知网站上某功能是失效的状况；但我却浑然不知。因此，决定想透过测试的观点来反观目前开发的系统缺陷并试着导入自动化测试的概念；另一方面是本身对於单元测试的主题从以前就略有耳闻，而且很感兴趣想认识测试的奥妙；此外，想透过这次的铁人赛养成撰写学习技术的心得分享，透过写文章让自己在反思对技术的了解。!

这系列主要分成三个部分：

1. 单元测试—基础：主要探讨单元测试的基本介绍如 3A 原则等。
2. 单元测试—核心技术：开始切入如何利用一些概念与技术撰写良好的单元测试如假物件、隔离框架。
3. 单元测试—情境及应用：在此部分会开始模拟一些情境并设计相对应的模式并测试。
   并在最後一天做此系列 30 天铁人赛的总结。