當我接觸到 Agile、XP (eXtreme Programming) 時
也常常聽見 TDD 這個名詞，在學習這門課前
僅約略知曉就是開發前先撰寫測試，以確保產品品質
心中不免晃過一絲絲「這只是測試人員推卸責任而已吧～」的念頭
（真的只有一絲絲喔～XD）
上完了第三天課，不只是顛覆既定的刻板思考
而是紮實有一種醍醐灌頂的感動。
Unit Test 在使用 TDD 開發時，除了單元測試的角色之外
更像是需求的描述者
但回歸到真正的實務情境上，往往遇到的不是從無到有的開發
而是從既有的架構中去新增額外的功能
於此， Unit Test 更像是重構時的保險裝置
追蹤了91大甚久～也見過不少次
歷經一番佈署爭取，終於讓老闆讓我去上課啦～～XD 感謝老闆！
先說結論，今天真的充實，也完全不覺得乏味
九個小時一下子就過了～～
之前也算有自行牛刀小試 TDD，很多卡關點今天完全解惑！
但後面竟然還有整整兩天課的內容，實在讓我非常期待！！
※ 本文僅雜記一些零碎的心得～
測試覆蓋率，沒錯，是個數字...
是個很可能出現在 KPI、驗收規格文件等地方的需求
只要把 unit test 上的 Assert 都拿掉，全部的 Function都呼叫一遍
就能輕輕鬆鬆的 100％ 了呢～
某種程度上來說的確很表面很沒意義
要如何讓這個數字具有價值也更有意義呢？
良好的物件封裝是 Production code 最基本的設計需求。
擁有良好的物件封裝，才能擁有更符合 FIRST 的 Unit Test。
一般測試會有三種需要驗證的狀況，最麻煩的物件互動該如何驗證？
該如何設計才能保持測試的獨立性，提高程式的可測性？
測試框架能夠提高撰寫 Unit Test 的便利性，增加導入的誘因！
好框架，不用嗎？
Unit Test。
從踏入軟體工作就聽過的名詞～
但以往只知道是小小的測試，就是要補一堆很廢的文件
以示對自己程式碼的負責。
腦中浮現的就是很不想面對的名詞，但又好像聽起來很有道理必須面對。
回想過去，沒有好的工具、沒有明確的 Unit Test 定義，完全就是放給他爛
最近自己也開始著墨這個部份～ 上完課終於有全面的瞭解啦！！
