在實際了解 Cucumber 的應用方式之前，我一直認為使用 Cucumber 撰寫測試是一件非常麻煩的事情，因為我們會需要實作許多 Step Definition（步驟定義）來讓文件中的某個行為可以被使用。
然而，當我了解到 Cucumber 的價值之後，就變成我優先選用的工具。
Behavior-Driven Development
在 Cucumber 的官網，明確地指出 Cucumber 是一種 Behavior-Driven Development（BDD，行為驅動開發）的工具，是以 RSpec 為基礎發展而來，不同的地方在於 Cucumber 可以在不同語言中被使用。
測試軟體的手段有很多種類型，像是整合測試、功能測試、單元測試等等，對 BDD 來說主要會專注在「功能」上的測試，也因此 Cucumber 所使用的 Gherkin 語言副檔名都常會是 .feature 進行表示。
在我過去的經驗中，我們會在 Ruby on Rails 專案中優先對 Model 類型的物件進行單元測試，這是為了保護 Rails 中習慣將「商業邏輯」放在 Model 中的關係。然而，我們真的能透過單元測試將完整的功能還原嗎？更多的時候是無法的，這時候關注功能的 BDD 更能實現這件事情。
RSpec 本身也是 BDD 框架，除此之外也很方便用來撰寫單元測試。
用文件溝通
雖然使用 RSpec 撰寫功能測試並不是問題，然而我們會面臨兩個困難。首先，如果遇到需要轉換語言的狀況，就需要完全重新開始。同時，在跟非 Ruby 工程師或者 PM（專案經理）、PO（專案負責人） 討論時，也會因為程式語言上的限制而卡住。
我們可以比較一下 RSpec 和 Cucumber 對同一個功能的呈現：
1RSpec.describe 'Simple Button' do
2 before { get '/' }
3
4 context 'when click button' do
5 it 'is expected to display HI' do
6 click_on 'Simple Button'
7 expect(response).to have_text('HI')
8 end
9 end
10end
1Feature: Simple Button
2 Scenario: Click button
3 When I click "Simple Button"
4 Then I can see "HI"
很明顯的，使用 Gherkin 能夠讓所有人很清楚的了解這個功能在使用上會有怎樣的效果，在跨團隊、職能的溝通上，可以有更好的效果。
在 Ruby 版本的 Cucumber 中，我們實際上還是會實際撰寫
click_on 'Simple Button'這類實現，但是我們還能有一份文件用於溝通跟討論。
專注於功能
因為 Cucumber 天生是設計給功能的測試工具，我們也能更好的把注意力從單元層級提升到功能層級，在許多思考上也就比較不會迷失方向。
這在很多不同領域都也類似的觀點，像是在繪畫的時候我們會從草稿開始，調整到適合的狀態後再繼續加入細節。放到軟體開發上，即使我們實踐了 TDD（Test-Driven Development，測試驅動開發）卻把注意力放在一個小單元上，那麼實現的軟體會是許多破碎的類別（Class）所構成的。
如果把注意力放在功能上，我們會得到的是幾個有著不錯內聚的模組，同時在思考設計的時候，也能夠更加的全面去思考實作涵蓋的範圍，而不會讓單一類別非常完善，卻難以跟其他人協作。