Mystic Pieces

這次很意外的旅居到其他國家（荷蘭），嘗試了很特別的出入金方式，網路上找不到類似的經驗分享，過程中都抖抖的。現在成功後，記錄一下，分享給需要的朋友。

當我接觸到 Agile、XP (eXtreme Programming) 時

也常常聽見 TDD 這個名詞，在學習這門課前

僅約略知曉就是開發前先撰寫測試，以確保產品品質

心中不免晃過一絲絲「這只是測試人員推卸責任而已吧～」的念頭
（真的只有一絲絲喔～XD）

上完了第三天課，不只是顛覆既定的刻板思考

而是紮實有一種醍醐灌頂的感動。

追蹤了91大甚久～也見過不少次

歷經一番佈署爭取，終於讓老闆讓我去上課啦～～XD 感謝老闆！

先說結論，今天真的充實，也完全不覺得乏味

九個小時一下子就過了～～  

之前也算有自行牛刀小試 TDD，很多卡關點今天完全解惑！

但後面竟然還有整整兩天課的內容，實在讓我非常期待！！

※ 本文僅雜記一些零碎的心得～

測試覆蓋率，沒錯，是個數字...

是個很可能出現在 KPI、驗收規格文件等地方的需求

只要把 unit test 上的 Assert 都拿掉，全部的 Function都呼叫一遍

就能輕輕鬆鬆的 100％ 了呢～

某種程度上來說的確很表面很沒意義

要如何讓這個數字具有價值也更有意義呢？

良好的物件封裝是 Production code 最基本的設計需求。

擁有良好的物件封裝，才能擁有更符合 FIRST 的 Unit Test。

一般測試會有三種需要驗證的狀況，最麻煩的物件互動該如何驗證？

該如何設計才能保持測試的獨立性，提高程式的可測性？

測試框架能夠提高撰寫 Unit Test 的便利性，增加導入的誘因！

好框架，不用嗎？

Unit Test。

從踏入軟體工作就聽過的名詞～

但以往只知道是小小的測試，就是要補一堆很廢的文件

以示對自己程式碼的負責。

腦中浮現的就是很不想面對的名詞，但又好像聽起來很有道理必須面對。

回想過去，沒有好的工具、沒有明確的 Unit Test 定義，完全就是放給他爛

最近自己也開始著墨這個部份～ 上完課終於有全面的瞭解啦！！