關於 #測試 的內容

對功能描述之後，我們需要將詳細的步驟寫下來，讓 Cucumber 知道該怎麼做來檢查這個功能是否符合預期，因此我們可以使用 Given、When、Then 來進行描述。

Cucumber 的測試撰寫基本上是非常容易的，因為我們不是去配合程式來實現測試，而是直接去撰寫測試後，讓程式去配合測試。

在實際了解 Cucumber 的應用方式之前，我一直認為使用 Cucumber 撰寫測試是一件非常麻煩的事情，因為我們會需要實作許多 Step Definition（步驟定義）來讓文件中的某個行為可以被使用。

然而，當我了解到 Cucumber 的價值之後，就變成我優先選用的工具。

我們對在不明原因重複訂閱的情況加入了 DuplicatedSubscription 的例外，然而這種情況是無法在驗收測試的狀況下被重現出來，因為使用者無法在正常狀況做到這件事情，在這種狀況下單元測試就非常適合。

因為我們還沒有完善所有的邏輯，因此儲存到資料庫將狀態持久化的機制可以先不處理，接下來我們需要建構不同的「測試資料」讓訂閱狀態有不同的呈現，而不是像現在這樣只有寫死的訊息。

過去我在寫測試的時候經常會有「這裡該測試嗎？」的疑問，然而這個問題其實可以從另一個角度思考，那就是「這些測試組以完善規則嗎？」去想，以我們第一個 E2E Testing 的測試作為例子，雖然可以通過測試，然而實作的內容只是一些假資料，我們需要用另一條測試從其他角度去驗證，讓實作最終變成我們預期的樣子。

通過規格的分析我們準備好了 E2E Testing 的文件，以及對應的步驟實現，然而在這個狀態下是無法順利通過測試的，因此我們需要進行一些實作。在只有一條測試的狀況下，我們可以用非常簡單的方法通過這個測試。

當我們有了關鍵案例（Key Examples）後，規格已經相對的明確，如果還能夠被自動化測試的話，是不是一件更好的事情呢？我們可以利用 Cucumber 來實踐 E2E Testing（端對端測試）讓我們模擬使用者實際操作來驗證規格的完善。

經過接近半年的連載，最後我們要來聊一下如何「加入測試」的問題，雖然我們了解到了各種撰寫測試的技巧，但往往我們是卡在不知道從何開始測試，因此跟大家分享一些實用的小技巧。

雖然我們沒有使用依賴注入的技巧，或者實作中有耦合的問題存在，在 Ruby 中因為語言特性的關係，我們還是有非常多方式可以進行測試，然而這也會讓我們的測試變得複雜。