自動測試與 TDD 實務開發(使用C#) Day 2 心得

回顧從第一天的基礎觀念說明，以及介紹一些好用的工具
(很重要！因為要容易導入，先決條件就是，簡單好用、容易上手不會造成太多的負擔。)，
再告訴我們如何將需求轉化為測試案例。

第二天告訴我們，
如何簡單容易(第二次了！)的建立整合測試保護目前已有的程式，
接著透過重構來償還這些技術債務，
最後再將重構後的程式建立單元測試加以驗證與保護。

而且！這課程是帶著你一步一步地做，讓你實際去體會：
從需求出發，建立測試案例，然後將測試案例逐步地完成測試，你的程式就完成了；
和你看了需求直接想程式該怎麼寫，其實差不了多少。

當思維從看到需求直接想 code 怎麼寫，轉化為如何透過測試案例講清楚需求，
慢慢地就會感覺到這樣寫程式，很輕鬆，不會有多餘的程式產生。
不然很容易落入一種寫很爽，但是會用到的沒多 少！
一旦真的要用可能還不符合需求......那不是很浪費生命嗎?
生命應該要浪費在美好的事物上，電視上不是常看到嗎?

上完這兩天的課程以後，我已經開始一步步的為手上的專案加上測試，
同時也期待最後一天的課程到來。

如果你對於用測試來保護你的產品、程式有興趣，可以參考看看。
如果正在導入，卻遇到阻礙(相信我，絕對有，親身體驗過)，你更要看看。

最後，雖然是使用 C# ，但是這梯也是有很多 php, java 的開發人員參加，
因為重要的是觀念，你用什麼語言，什麼工具都是其次，
在各種語言上絕大多數應該都找的到對應的工具才是，
所以別太擔心，也會有很親切的助教協助你的！

講師的FB部落格 91 敏捷開發之路

FB 原文
‪

自動測試與 TDD 實務開發(使用C#) Day 1 筆記

前言==========
這次運氣不錯，有幸報到第四梯的課程，
其實在第三梯的時候就想報名了，不過剛好有兩位好友先後結婚，
只好期待 Joey 的第四梯了！
也感謝 Joey 用心準備與持續精進的課程內容，
這應該也是一種早買早享受(提早進入這領域)，晚買享折扣(學到更多)的概念吧！

對課程有興趣，或是想要導入測試來強化產品，真的大力推薦 Joey 課程，網址如下：
https://skilltree.my/events/mbh
一定是物超所值的。

另外是他的粉絲團『91 敏捷開發之路』
https://www.facebook.com/91agile
以及點部落『In 91』
http://www.dotblogs.com.tw/hatelove

心得==========
第一天的主軸在於：

【老闆是花錢請你來寫 production code 不是來寫測試的！】

重點還是在開發，不是測試！
測試只是工具，輔助你驗證 production code 是符合開發者的想法，
滿足顧客的需求！

在團隊開發中最常遇到的狀況：

1. 測試環境和正式環境有些因素導致無法驗證，例如：資料庫、第三方的 API 等
2. 不知道錯在哪裡！一段冗長的流程結果錯了，必須要從頭追到尾
3. 上頭問起那些功能測過......提不出證據
4. 修 A 壞 B，修好 B 結果 A 又往生了！
5. 平行開發，只憑想像或是文件，整合的時候就是場災難

這些問題都可以仰賴撰寫測試，來降低開發成本，
BUG 越早被發現，處理成本越低，
整個就是早期發現早期治療的概念！
所以寫測試就像是在健檢一樣，必然會有一些成本的支出，
但是效益絕對是很大的。

Unit Test 是：

1. 最小測試單位
2. 外部相依為零
3. 不具備商業邏輯
4. 測試案例之間相依為零
5. 一個測試案例只測一件事情

Unit Test 的特性是：

1. Fast
2. Independent
3. Repeatable
4. Self-Validating
5. Timely

簡稱 FIRST

3A 原則

1. Arrange
2. Act
3. Assert

要驗證的東西

1. 回傳值
2. 狀態的改變
3. 與外部的互動

單元測試的意義在於模擬外部如何使用測試物件，驗證行為是否符合預期！
所以應以需求為出發點，而不是為了測試而測試，要記住是在開發！
非公開的方法，應該透過測試公開的方法而被測試，
沒有涵蓋到表示兩種可能：

1. 測試案例代表性不足
2. 沒被涵蓋到的程式，沒有存在的價值(永遠不會被用到！)

後記==========
其實在前公司曾經試著要導入自動化測試，想藉著導入測試提升產品的品質，
確實遇到了一些阻力，同時也因為自己對於測試沒有充分的了解，
沒有持續改善的觀念，最終仍以失敗收場，相當可惜！
希望在這課程中，能夠提升自己對於自動化測試的認知與能力，並且在往後的專案中落實。