BDD?

What - 什麼是 BDD

BDD 的全名為 Behavior-driven development 
BDD 是透過 DSL ( Domain-specific language )來描述系統的行為。

Why - 為什麼要使用 BDD



因為使用者的需求，要轉變成系統的程式碼，中間的落差相當大。


BDD 的效益在於，能讓使用者、測試人員與開發人員，可以用一樣的方式來描述與了解需求。


由我自己來說的話：若需求文件就是一個可執行的程式碼，那麼只要執行需求文件就能確定開發的內容是符合需求的！！

When - 什麼時候使用 BDD

當撰寫好驗收測試案例，建立好系統雛形。開始準備著手開發實際的程式碼前，使用 BDD 來描述「驗收測試案例」所對應的「系統行為與腳本」。

Who - BDD 該由誰來撰寫



建議由開發人員主導，測試人員輔助，確定這樣的 Scenario 是否為測試人員所預期的，是否滿足了驗收測試案例。但測試案例是由 user story 而來，因為第一層的 acceptance test cases 就是用來定義 user story 要滿足哪些 scenarios 才算完成。


確認完畢後，開發人員就可以直接從 code template 著手進行 TDD 。

Where - BDD 的腳本該放在哪裡



BDD 的腳本，也就是 scenarios，其實就是產生測試程式的骨架，只是是使用 DSL 來描述罷了。


而 BDD 的內容，其實就是 TDD 的測試案例，可能包含了整合測試與單元測試的範疇。


所以 BDD 的專案，可直接視為整合測試專案或單元測試專案，建議這兩者要分開，以便開發時可以迅速執行單元測試，在持續整合的 server 上，則可以執行到完整的測試程式。而 scenarios 可以透過一些工具，掛載在持續整合 server 的 report 上，進而成為一種 live documents ，既透明、又即時，而且每個人都可以看得懂。

最後補充敏捷的四條宣言
  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan 







部分內容引用自：https://msdn.microsoft.com/zh-tw/library/Dn308251.aspx

留言

張貼留言

這個網誌中的熱門文章

postman有跨網域神力啊

今天幫賈賈查個東西 要怎麼把curl 的action轉成js或者jquery的ajax code 恩.... 看起來是完全可行的（畢竟我是個菜鳥 但我從六點多開始試到凌晨一點多都是失敗的....不論各種debug, 自己開web api比對resource, response 後來利用了"postman cross domain" 以及 "curl cross domain" 查到了 Regular web pages can use the XMLHttpRequest object to send and receive data from remote servers, but they're limited by the same origin policy. Extensions aren't so limited. An extension can talk to remote servers outside of its origin, as long as it first requests cross-origin permissions. Ajax calls can only be made to URLs within the same domain. 然後有一篇神文說“你可以用jquery ajax 做到cross domain"，他的方法是利用jquery ajax傳給一個php頁面，再讓php用curl的方式把remote data吐回來，好複雜啊這～ 文章的最後，到底為什麼postman可以cross domain而我就不行呢？ https://developer.chrome.com/extensions/xhr google developer的文章中有寫道 （非拿不可的話，似乎可以用JSONP或者CORS來解
閱讀完整內容

angular ui-router 變更網址列的方式！ （偷渡關於移除URL中的#

在angular提供的ng-router或者third-party的ui-router中，在裡面這樣那樣的切換頁面過程中，瀏覽器的網址都會變更，但其實如果直接輸入那個網址，卻會 404 !! 應該是因為 angular在切換頁面的過程中，不希望刷新頁面，所以使用了類似partial view的概念，對需要更新的部分用http request去把需要的content拉出來，並且將網址列的內容更改為本身router的state對應到的url !! /*偷渡一段在這邊 angular默認會使用一個#符號來對url進行route 例如 http://tony.com http://tony.com/#/home http://tony.com/#/setting 如果不想要出現這個#的話 要用$locationProvider，並且設置相對連接的起點路徑 在app.config中加入 $locationProvider.html5Mode(true); 在index的head裡面加入 <base href="/"> */ 而這邊要提到的就是將網址列的內容改為本身router的state對應到的url，這是如何做到的呢～～ 這是使用了html5的history api來達成，可以透過window物件->history物件瀏覽瀏覽器的歷史，並且有提供一些方法讓你可以在歷史紀錄中前進以及後退要在歷史紀錄中往後移動，可以： window.history.back(); 同樣的，你也可以往前移動window.history.forward(); 你可以用 go() 方法來從頁面的 session 歷史記錄中載入特定紀錄， 以目前頁面的相對位置而定（目前的頁面想當然爾是 index 0） 往前一頁（等同於呼叫 back()）：window.history.go(-1); 往後一頁（等同於呼叫 forward()）：window.history.go(1); 你可以查看 length 這個屬性來取得目前瀏覽歷史的總數 ： var numberOfEntries = window.history.length; 加入和修改歷史紀錄 HTML5 加入
閱讀完整內容

google smtp好麻煩啊～

1 .將「安全性較低的應用程式存取權限」設為「啟用」 找到 Google 帳戶內找到「安全性較低的應用程式存取權限」的設定 或是直接開啟此網頁 https://www.google.com/settings/security/lesssecureapps 登入後設為「啟用」。 2.解除人機驗證鎖定 直接開啟此網頁 https://accounts.google.com/b/0/DisplayUnlockCaptcha 點下「繼續」。 3.啟用兩步驟驗證，再設定應用程式專用密碼 直接開啟此網頁 https://accounts.google.com/b/0/SmsAuthConfig?hl=zh_TW ，啟用兩步驟驗證。 不過要注意的是，以後在尚未信任的裝置上用email跟密碼登入 Google 帳號，會變成無法使用，一定還要再次透過電話或簡訊驗證，才能登入帳戶。 開啟此網頁 https://security.google.com/settings/security/apppasswords?pli=1 ，讓它產生一組應用程式專用密碼，然後把寄件程式內的 google 密碼換成這組應用程式密碼。 注意哦！這組應用程式專用密碼只能登入一個地方，如果把這組密碼先拿來當smtp寄信，又再拿去登入其他東西，後來那個是無法登入的。
閱讀完整內容