YinHong coding notes

『你的問題是甚麼？』 『你要用甚麼方法來解決問題？』 ※ Unit Test 確保程式想寫的和你想的一樣 『說明文件往往過時無參考意義、程式出錯了不知道錯在哪裡、需求異動常常改東壞西』，因此你需要 Unit Test，透過單元測試可以讓你快速發現問題之所在，雖然初期會花費時間與成本在撰寫看似毫無意義的程式，但是在系統由開發進入維護後，效益就會慢慢顯現出來。 那 Unit Test 有甚麼特性呢？ 最小的測試單位 外部相依性為零 不具備商業邏輯 測試案例之間的相依性為零 一個測試案例只測試一件情 要達到這些特性，程式碼重構還是必須的，過去在撰寫程式的時候，我們往往讓物件與物件之間十指緊扣、緊緊相依。這時我們就應該使用介面 Interface，斷開物件與物件糾結的鎖鏈。 過去我們在撰寫程式的時候，常常一個函式數十行或長達數百行，讓程式不僅無法閱讀也無法達到可測試性，這時我們就必須要重構，將各別處理的邏輯獨立開來，這樣我們才能夠讓這所謂的『黑箱』慢慢變成『白箱』。 但是對於已經發臭到不行沒人敢維護的程式碼，到底該怎麼樣重構才好呢？我們可以透過黑箱的測試先錄製測試的結果，比方說用 Firefox Plugin Selenium 來錄製測試案例，再來進行程式碼的重構。 當有了這樣的測試案例來輔助，讓你的程式碼即便再『黑』，擦上 SKII 也能夠讓你『白』回來！ ※ TDD 確保你先想清楚才動手寫 當你會寫單元測試後，接下來就可以朝著 TDD 的步伐邁進！ 所謂的 TDD 就是 Test-Driven Development 測試驅動開發。 這樣的開發方式對我來說算其實是相當的陌生，過去的開發方式我們 習慣先以需求為主 ，然後構思這個需求需要那些功能，再針對這些功能進行開發。在這樣的過程中往往會過度發散所需要的功能，常常會考量東、考量西的做了一堆例外的過濾。 而 TDD 就是以 用『測試』來輔助『開發』 ，我們先寫好 Test Case，才進行功能的開發，讓 Test Case 從紅燈變成綠燈，才繼續撰寫下一個 Test Case。透過這樣的 『 輔助』 ，可以讓你更 『專注』 在 Test Case 的處理，才不會過度發散浪費不必要的時間在無謂的功能上面。 就跟安西教練

因為測試的原因我不得不要學會關於Promise的相關知識啊～～ 偏偏中文相關文章又很少很難懂＝＝～ Propagation Promise 中 then return 的東西大有玄機，有三種情況 Promise: 下一個 then 會是一個全新的 Promise Value: 這個 Promise 已經被滿足了，之後串接的 then 都會是此 Value Throw exception: 這個 Promise 發生問題，之後的 then 都不會執行，會改執行 fail 的 callback Chaining 就是上述第一點，可以改善 Callback Hell ，讓 nested 的 callback 少一點return getUsername() .then(function (username) { return getUser(username); // new promise }) .then(function (user) { }); Combination 當有多個 Promise ，而你想要等這些 Promise 都執行完(fulfilled)，才要執行下一步的話，可以使用這個非常 awesome 的用法Promise.all([promiseA, promiseB, promiseC]).then(function () { console.log "A, B, C has done!" }); Handling Errors 除了 then 之外，還有 catch 的 method 來接 chaining 過程中有發生的 exception ，用 done() 會讓未處理的 exception 噴出來 Promise Creation 假設我們要把 readFile 包裝成 Promise ，可以這麼做var deferred = Promise.defer(); FS.readFile("foo.txt", "utf-8", function (error, text) { if (error) { deferred.reject(new Error(error)); } else { deferred.resolve(text);

在安裝好 1. VS2015 RC 2. iTunes最新版 之後～～ -->開啟iTunes並接上裝置 -->開啟VS2015RC   -->新增專案   -->選擇"Javascript"-->"Apache Cordova Apps"   -->輸入專案名稱後按ＯＫ   -->編輯專案中config檔，在 Application Id 中輸入**************（這邊找我），並儲存   -->在上方欄位中選擇 "Tools" --> "options" --> "Tools for Apache Cordova"   -->選擇 " Remote agent Configuration "，並將內容修改如下圖（IP也找我）   -->將建置設定改為這樣，即可開始建置！   -->建置完成後在iTunes中的手機資訊畫面進入app區塊   你會看到這個畫面    選擇你所建置的app並且 按下旁邊的按鈕（剛建置完會顯示"更新"ＯＲ"安裝"） ，最後按下下面的同步即可將應用程式安裝進手機裡了！！！    有任何建議請跟我說，我會馬上修改！

若iTunes非最新版，則更新到最新 1. 在裝置管理員中，找到Apple iPhone，右鍵>內容 2. 上方選單 驅動程式>更新驅動程式 3. 選擇"從清單或特定位置安裝(進階)">下一步 4. 選擇第一個"在這些位置中尋找最好的驅動程式"，並勾選"搜尋時包括這個位置"     然後瀏覽選取以下路徑：C:\Program Files\Common Files\Apple\Mobile Device Support\Drivers     然後下一步>完成！

----E2E 可以幹麻～ 確認畫面的引導以及協調性，提升使用者體驗 模仿使用者行為 記錄行為供使用 必要性～ 確認使用者與開發者間認知的一致性 確保第一印象 bug越修越錯 ～單元間有獨立性，也有疊加的部分（獨立性的共通性 容易越改越錯 ～只測個人的部分，沒有協調 工具 selenium等等～～ E2E可在開發後期在寫 ----Backend 測試要～～ 1.Define Requirement 2.Define Flow 3.上啊！！ 規格分成 1.文字 2.腦 3.可被執行的規格 方法 -->RED-->GREEN-->Refactor CI(持續整合 -->有變就build-->測試是否正常-->馬上修 CI Tool -->Jenkins   or  strider

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 ，既透明、又即時，而且每個人都可以看得懂。 最後補充敏捷的四條宣言 Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration