我的BDD物語1
我的BDD物語1 從開始使用TDD之後一年多，發覺不管是解Bug還是做Enhancement，沒有寫Test就會覺得全身不對勁，在這段期間，也看到了許多TDD進階到BDD的分享文章，像是 INTRODUCING BDD ，最有感的應該是這篇 WHAT’S IN A STORY? ，看了之後發覺原來寫User Story是很簡單的，有固定的格式，也可以很好的描述出系統的行為。之前看到那種厚重的文件裡面內含的Use Cases，我心想，到底這種文件誰會來維護，一定不是Developer...，不是Develper維護的結果就是文件跟不上code，基本上這種文件都要準備的很完整的形式，是給某些走 重裝 軟體流程的團隊，而我們寫code的時間都不夠了，哪有時間在那邊改一堆奇奇怪怪的Word、Excel、PDF。而以BDD的方式來作，只要寫出如下的Story: 就可以就寫Behavior Test，文件格式也很簡單，用普通文字檔就可以，也可以用Markdown之類的格式來呈現，在有需要與Product Owner或Feature Owner討論的時候就可以派的上用場，討論完馬上就可修改，寫Behavior Test時一想到其他Case也可以修改。 故事是這麼開始的 有了TDD的經驗與BDD的知識之後，我在開發N功能時就實際應用上去，N功能對我而言是有點莫名其妙的功能，感覺與我們系統的設計背道而馳，這部份我就不多說，總之，開了一次又一次的會，大概對實際需求有個譜，在還沒有開始寫Code之前，我就先寫出了一個又一個的User Story，其實撰寫User Story也沒辦法花太多時間，一開始大概一兩個下午斷斷續續就完成初版，由於系統裡還有很多面向，例如備份、升級、組態模板、事件、還有各式各樣的使用者行為，有些面向我也沒有實際接觸過，所以只能寫出User Story的Title。 接下來開始寫Code之後，我的方式是每個User Story對應一個Class，每個Scenario對應一個Test Method，每個Scenario都代表User的一個行為，當然也有系統因為狀態變化的行為。以TDD的方式來做，當然就是先把Test寫好，然後再去修改Production code裡面的內容，來滿足Test的結果。這個作法的好處在開發時我體會到幾項： 一邊寫會一邊思考...