RSpec 與測試驅動開發的思考方式
日前翻舊文時，看到一篇關於 RSpec 的好文章。
這篇文章有條不紊的說明我們是如何利用 rspec 這套工具，引導我們的軟體開發流程。
根據 rspec 中的 spec 字眼，我們可以將 rspec 解釋為一種用於描述軟體規格的的特定領域語言(Domain Specific Language)。由於軟體規格就是應用軟體表現出來的外在行為，所以跟隨 rspec 此類工具的設計流程，被稱為「行為驅動開發模式」(Behaviour Driven Development)。這種開發模式屬於測試驅動開發模式(TDD)的高階形式。
有些開發者誤以為 Agile/XP 方法不做設計工作。事實上並非如此，只是我們的敘述形式不同罷了。 例如我的舊文《先說故事再動手設計, 從一個簡單故事看 Test Driven Development》，和 Neal Ford 的這篇《Behavior-driven testing with RSpec》，都依循相同的思考模式實現設計工作。所謂設計、故事／使用案例、測試案例都是同一事物的不同面向、不同的表達形式。基於 Agile/XP 追求降低重複性的傾向，我們不喜歡重複做同一件事。因此，我們認為設計工作與測試工作之間應該不分彼此地結合在一起。
rspec 就是在這種思想之下出現的工具。它基本上就是一種測試案例形式。但與一般的 unit test 工具不同之處在於 rspec 採用了更貼近口語文件的敘述形式。按照 Agile/XP 編程方法的傳統習慣(Source code is Document)，一份 rspec 文件，既是軟體規格書、測試計劃書，也是測試案例源碼。rspec 貼近口語文件的敘述形式，使其作為軟體規格書時更具可讀性。當我們在編寫一份軟體的 rspec 文件時，就是一次編寫軟體規格、使用案例以及測試案例三種文件。
各位在閱讀《Behavior-driven testing with RSpec》時，除了觀看 rspec 的用法之外，也應細細體會這種開發模式會帶來的好處。