以往工作的經歷，身邊工程師對測試的認識

對於目前撰寫程式的開發員來說，「測試」一詞大多是不會感到陌生的。甚至很多人也可說出測試大致上的目的；然而，就我目前所接觸的軟體開發公司 （大多是專案公司） 中鮮少有導入測試的專案或產品，部分擔任 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 天鐵人賽的總結。