Recommended
More Related Content
What's hot
Viewers also liked
Viewers also liked (20)
Similar to 前端測試
Similar to 前端測試 (20)
前端測試
- 1. 前端測試
- 2. 大綱 • 測試概要 • TDD • BDD • CI/CD
- 4. • 因為寫測試程式很花時間…. • 因為需求一直改,光改Production Code就改不完了…. 開發人員的心聲
- 7. RiskCostHigh Low Nothing Too much Sweet Point 是否寫測試的全局觀
- 8. 可是時程太趕阿!
- 9. 哼!看來你不知道TDD
- 10. 它是另一種寫測試的方式?
- 11. 它是開發方法啦!
- 12. 不管怎麼看都只是寫測試呀?
- 13. 測試只是它附帶的 產物啦!
- 14. TDD的作業流程
- 15. • Fast • Independent • Repeatable • Self Validation • Timely
- 16. • Mocha是一套支援TDD/BDD的前端測試框架 • Mocha可以和多種測試平台結合 • 許多前端的斷言庫都有與Mocha的結合 前端測試框架:Mocha
- 17. Mocha使用技巧 • 支援ES6/7: • 需在指令加上參數 –compilers • 執行多個測試檔案: • 需在指令加上參數 –recursive • 範例: npm alias “test”:”mocha --compilers js:babel-core/register --recursive” • 若需要的參數過多,可在test資料夾中添加mocha.opts檔案,並在檔 案中加入所需要參數,每一個參數以換行符號區隔
- 18. • 提供測試框架在斷言方面的協助 • 解決物件比對的問題 • 以口語的API串接方式,讓開發人員能夠更直觀 • 提供Promoise物件的斷言 前端斷言框架:Should.js
- 19. • 為react-addons-test-utils的包覆Js庫 • 提供jQuery的查找內容API,並支援鏈式呼叫 • 具有Shallow/Full兩種模式,依需要選擇適合的 • Shallow僅載入第一層Component • Full可以存取真實的DOM物件 • 允許模擬DOM事件: click,select…. ReactJs測試框架:Enzyme.js
- 22. 我切的不對? 應該不是以API為單位 僅完成單一職責的程式碼區塊 FrontEnd BackEnd TDD Master
- 25. 還沒準備好API Server? 我們的IT部門…. 單元測試不需要外部環境啦 FrontEnd BackEnd TDD Master
- 26. • 提供四種模擬方式: • Stub • Mock • Spy • Fake • 解決單元測試需要環境隔離的需求 前端擬物框架:Sinon.js
- 27. • Stub: • 會覆寫到原函數的行為,因此,可以直接指定回傳的物件或是直接拋出例外。 • 適用時機: • 覆寫掉需要與外部環境協作的程式碼區塊 • 強制觸發例外,調控程式區塊執行的路線 • 可用測試非同步程式碼區塊 • Mock: • Stub的強化版;額外添加的特性在於程式碼區塊執行的行為測試。 • 適用時機: • 可以使用行為函數來平估指定程式碼區塊 的行為 • once • withArgs
- 28. • Spy: • 主要在於擔任CallBack函數的替身,藉此潛入到函數中取得所需要的資訊。 • 適用時機: • 取得函數被執行的次數 • 取得每次被呼叫時傳入函數的輸入參數 • 取得函數本次呼叫所回傳的物件 • 取得函數會拋出的例外物件 • Fake: • 可以偽造XMLHttpRequest/Server/Timer。 • 適用時機: • 針對Ajax的測試處理(有很多工具可以取代) • 針對Backend API的測試處理,相較於XMLHttpRequest有更多的在Response上的控制 • 對於Timer類的程式碼區塊
- 29. • 與Mocha.js有著極佳的整合 • 可以取得程式碼的測試覆蓋率 • 共有四項指標: • Statements • Branches • Functions • Lines 測試覆蓋率:Istanbul.js/Isparta.js
- 30. • 完整結合下列工具: • Mocha • Babel • Istanbule/Isparta • React • 以簡單的組態方式,就能夠輕鬆產出測試覆 蓋率的報表 整合Istanbul/Isparta的Gulp套件: gulp-jsx-coverage
- 33. 需求不是說要這樣嗎? 客戶和PM說不是ㄟ 這是TDD的硬殤,這時候就該 BDD登場了 FrontEnd BackEnd TDD Master
- 34. Stories Behaviour Application Exercise expectations against Matches to QA BA Developer 職責與工作分配
- 37. BA有寫User Story,但還是 似懂非懂 我覺得是描述方式有問題 User Story需具備一些要素: • 簡短但完整的Story描述 • 需要有允收測試準則 • 要開一次Planning Meeting FrontEnd BackEnd BDD Master (跳槽了)
- 39. • 系統管理員需先登入後台系統 • 系統管理員的帳戶需具備管理使用者帳戶的權限 • 系統管理員操作的使用者帳戶需已註冊成功,並且 該使用者帳戶未被啟用 • 當系統管理員操作的使用者帳戶已處於啟用中,系 統需以彈跳視窗呈現提示訊息: “該使用者帳戶已啟用” • 當使用者帳戶啟用後,該使用者可隨時登入到前台 系統 • 當使用者帳戶未被啟用,該使用者無法登入到前台 並且前台會以彈動視窗呈現提示訊息: “尊貴的客戶,您的帳號尚未被啟用,請通知客服為 您處理” 允收測試準則 前置條件 操作描述 細節陳述
- 41. 客戶和PM每次改需求都說: 這不是改一下就好了嗎 還常罵我太”工程師”了 那是因為他們沒有”和”你 們一起工作,所以彼此溝通 和認知上有差異,BDD正是 聯結彼此的一種方法論 FrontEnd BackEnd BDD Master
- 43. 前端BDD框架:Cucumber • 以Gherkin文法描述需求 • 提供工具,可讓Gherkin的語法轉為測試程式 • 可與多種測試框架和平台整合
- 45. 在一起工作 誰負責需求的部份呢?
- 48. • 由Product Owner/BA講述本次Release的所有需求 • 與會人需釐清所有需求才能結束會議 • 遵守Time-Box,時間到了就擇期繼續開會
- 55. 前端程式碼規範框架:JSLint • 檢查與審視程式碼是否符合團隊規範 • 可與Git Hook協作 • 可自行添加和定義規範
- 57. 我知道還有整合測試 還聽過…冒煙測試 測試的確還有很多種 但是每種測試,都傾向 能夠自動化 FrontEnd BackEnd Testing Master (跳槽again)
- 60. 前端整合測試框架:NightWatcher • 包裝Selenium Driver,提供更方便的API • 可與Cucumber.js及Mocha整合
- 63. 時機和環境的差別? 感覺測試和開發是兩個世界 測試和開發可在CI(持續 整合)中被結合在一起 FrontEnd BackEnd Testing Master
- 64. 持續整合
- 65. 持續交付
- 66. 呢喃 • 只有瞭解需求才能做好測試 • 單元測試要注意最小單位和環境隔離 • 整合測試需要備妥環境,成本很高 • 持續整合是團隊自動化的基石 • 持續交付是敏捷的基石