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