在軟體開發中，有許多測試的流派，像是 TDD（Test-Driven Development，測試驅動開發）就是其中之一，除此之外還有 BDD（Behavior-Driven Development，行為驅動開發）等等不同方式，根據不同的情境選擇適合的測試方式也會是一個重要的技巧。
測試與規格
從測試方法的名字中可以很輕鬆的了解到，TDD（測試驅動開發）的前提就是先寫測試，然後再去開發我們的系統。要達成這樣的條件，就會需要有明確的規格才能夠實行。假設我們沒辦法明確的定義出像是「當日用品跟清潔用品一起購買時折扣 10%」的規格時，我們基本上就可以預期測試驅動開發會變得非常難以進行，因為我們無法給出一個詳細的 User Story（使用者故事）並且根據這些資訊推導出所需要的測試案例應該如何撰寫。
先測試的好處
然而，我們可以反過來思考，假設我們希望先進行測試的話，是否應該反向的驗證規格是否有所缺漏。
基於這樣的前提，我們可以將測試驅動開發想像為一個「反思」的技巧，當我們拿到「當日用品跟清潔用品一起購買時折扣 10%」的條件時，是否還需要更多的資訊呢？舉例來說，我們是否需要限定在特定時間折扣、是否有折扣的額度上限等等
當我們釐清規格的時候，大致上也對當下的需求有了更清晰的理解，此時再去根據測試的限制撰寫實際運作的程式，就能夠更好的控制範圍以及減少錯誤。
穩定的發展專案
如同測試的目的所說，測試能夠讓工程師更勇敢的修改，也會在測試逐步完善的過程中減少反覆驗證的成本，逐漸的加速開發。在這樣的狀態下，我們的專案實際上就是穩定發展的，因為人為疏失或者意外造成的影響會逐步地減少。
然而，在不同的情境下使用不同的測試方式依舊還是有必要的。因為 TDD 大多是以「單元」測試為前提，對於產品經理或者專案經理來說是難以直接給出確切的規格。而 BDD（行為驅動開發）可以搭配像是 Cucumber 這類工具，先由工程師設計對應的關鍵字，讓非工程師可以用「描述行為」的方式來定義功能，先進行一個「大方向」的規格定義，再由工程師確認細節夠撰寫「小單元」測試來確保每一個零件都是正常的。
封面圖片使用 Unsplash 上 Lauren Sauder 的作品，有想聽的主題可以透過匿名問卷告訴我，想了解專業的技術主題可以到弦而時習之找找靈感。
