單元測試是開發軟體產品過程中，與品質、設計相關最重要的基本工程實踐，如果不會單元測試，很多重構無從下手。如果不會單元測試，無法駕馭測試驅動開發。
許多公司往往為了 KPI 需要數字，所以將 code coverage 訂了個指標來「強暴」開發團隊，甚至要求團隊「一定」要用 TDD 來開發所有程式。這一切都是不求甚解的為了追求數字的迷思，本篇文章將補上我對於「code coverage」與「看待 TDD 的正確角度」的見解。
測試驅動開發 TDD 不只是測試先行而已，Uncle Bob 提出了 The Three Laws of TDD 來說明，從紅燈到綠燈的過程中，你該遵循的原則與規範。遵守這三條原則，能讓你比較自然地進行 baby step，即時重構，聚焦目標。
本活動將以實務的例子，讓大家針對真實需求進行實例化需求分析、學會如何為真實的 legacy code 進行單元測試與重構，最後透過 TDD 的練習與比較，來深刻體悟 TDD 如何幫助我們化繁為簡、迭代式地進行產品增量的開發。