經過一系列的實作，Cucumber 的特色讓我們很容易的在不同語言、環境中轉換，同時又能夠扮演文件的角色，更難得的是他可以在不同語言中使用，這讓我們在未來對應不同需求時能有更大的彈性。
介面
近年常會聽到 Design by Contract（契約式設計）的概念，卻一直沒有很完善的理解。然而，實際上就是指「介面」的設計。
舉例來說，我們要呼叫一個 API（Application Interface）的時候，約定好的格式就是介面，而這樣的概念普遍存在於程式設計中的各種階段。像是 UI（User Interface）是跟使用者約定好的操作方式、MVC（Model-View-Controller）則是約定好三種類型物件負責的處理的範圍。
那麼文件如果以約定好的格式撰寫，自然也就構成了「介面」那麼我們去「實現介面」就能在不同語言、環境中應用，正因如此 Cucumber 扮演了 BDD（Behavior-Driven Development）的文件介面，讓我們可以在不同的環境中呈現出相同的測試。
累積
要實踐測試會遇到不同困難，像是環境搭建、撰寫適當的測試等等。原本在某種語言所撰寫的測試，如果無法帶到新的語言，那麼可能放棄測試或者轉移，這會對軟體開發長期維護上造成不少影響。
假設我們的測試跟文件是可以繼續被延用，那麼撰寫測試的價值就會提高很多。以 Cucumber 這樣的工具來看，確實讓我們在使用新語言、新工具（或框架）的時候可以沿用同一份測試，那麼只要持續的撰寫測試，累積越多就越有價值。
尤其 Cucumber 還同時涵蓋了「規格」和一部分的「測試」可以讓我們讓規格、測試、實作三者更加貼近，進而減少多餘的實作，從這個角度來看引入 Cucumber 是相當有有價值的。
存在已久
實際上 Cucumber 已經存在數十年以上，不是一個很新的方法。我在對「實作」的探索達到瓶頸的時候向外探索，意外發現許多技巧在軟體開發的領域中存在許久，而且非常有用，卻很少有人知道。
隨著時代演進，可能會有些許的變化跟改變。然而像 Cucumber 這類工具和技巧，卻一直都有被使用，我們卻沒有機會很好的深入去瞭解背後的應用與思考，最後漸漸的用機械式的方式去撰寫測試，而真正的測試我們只需要涵蓋會被使用到的，以及捕捉到問題後繼續補充進去的部分就非常足夠。
這也是為什麼我們能夠把測試當作「安全網」看待，當我們涵蓋足夠的功能時，不論修改哪些地方，只要會造成問題都能夠被發現，那麼每一次的重構、清理程式碼就會變得非常安全。
這也是我選擇推廣 Cucumber 作為開發工具的理由之一，比起實作跟技術細節，我們更能關注實際被使用到的功能。