# **if (Testing) { ? }** --- ## 為何需要測試? ![](https://i.imgur.com/Ki8CVNn.png) --- ### 自動測試的好處 - 產出的質量 - 減少人工測試的複雜度 - 測試案例可以更了解開發的需求 - 測試驅動開發 - 以長遠來看大幅減少開發時間 --- ### 壞處呢? - 增長了開發時間 - 需求時常改變增加測試程式維護難度 - 學習成本 --- ### 反對理由 - 寫單元測試比較費時,有這個時間不如多做幾個需求 - 測試在驗收的時候對頁面的功能都會操作一遍,寫單元測試相當於做無用功 - 後端提供給前端的接口需要保證質量,因此需要做單元測試,但前端很少需要提供接口給其他人 --- ### 使用的理由 - 業務比較複雜,前端參與的人員超過3人 - 公司非常注重代碼質量,想盡一切辦法杜絕線上出bug - 你是跨項目組件的提供方 - 你在做一個開源項目 --- ### 測試的類型 - 端對端測試 (E2E testing) - 單元測試 (Unit testing) - 整合測試 (Integration testing) --- ![](https://i.imgur.com/fPCWiZF.jpg) --- ![](https://i.imgur.com/GXbhRHu.gif =60%x) --- ![](https://i.imgur.com/ejRRD6N.png) --- ![](https://i.imgur.com/xWoUTKK.gif =60%x) --- ![](https://i.imgur.com/2xaKdOL.png =150%x) --- ### TDD & BDD ![](https://i.imgur.com/qPqMQzq.png =120%x) --- ### TDD 一句話簡單來說,就是先寫測試,後寫功能實現。 TDD的目的是通過測試用例來指引實際的功能開發,讓開發人員首先站在全局的視角來看待需求。 --- ### BDD 行為驅動開發要求更多人員參與到軟件的開發中來,鼓勵開發者、QA、相關業務人員相互協作。 BDD是由商業價值來驅動,通過用戶接口(例如GUI)理解應用程序。 --- 不管是什麼~~弟弟~~都是為了同一個**夙願** - Do the right thing(產品做對) - Do the thing right(品質做好) --- ## Jest & Enzyme ![](https://i.imgur.com/RnbwS7a.jpg) --- ## **Jest 主要針對Unit Test** --- ```javascript= ///sum.js export const sum= (...a: number[]) => a.reduce((acc, val) => acc + val, 0); ``` ```javascript= //sum.test.js test('basic again', () => { expect(sum(1, 2)).toBe(3); }); ``` --- ## Enzyme 主要針對 E2E Test ## 搭配jest使用 --- ```javascript= // welcome.js export default class Welcome extends Component { render() { return ( <div>Hello world!</div> ); } } ``` --- ```javascript= // welcome.test.js import React from 'react'; import { shallow } from 'enzyme'; import Welcome from '../src/containers/welcome'; describe('Welcome', () => { it('Welcome renders hello world', () => { const welcome = shallow(<Welcome />); expect(welcome.find('div').text()).toEqual('Hello world!'); }); }); ``` --- ## **或是另外一個選擇** :tada: --- ![](https://i.imgur.com/CMzbEUY.jpg) --- ### 如果b2b搜尋面板有測試? ![](https://i.imgur.com/W1OIG7H.png) --- ### 一個E2E的Demo,以b2b-activity為範例 1. 開啟瀏覽器進入指定的url 2. 將搜尋面板切換到票卷>驗證是否有到票卷 3. 測試快速選單(dtm)功能>驗證是否正常 4. 測試關鍵字功能,輸入關鍵字>驗證api結果 5. 表單送出 6. 切換window 7. 驗證url為預期(是否為送出結果) ***end*** - 備註:要otp登入所以直接驗證是否再登入頁 --- ```flow st=>start: 開啟瀏覽器進入指定的url op1=>operation: 將搜尋面板切換到票卷>驗證是否有到票卷 op2=>operation: 測試快速選單(dtm)功能>驗證是否正常 op3=>operation: 測試關鍵字功能,輸入關鍵字>驗證api結果 op4=>operation: 表單送出並切換window op5=>operation: 驗證url為預期(是否為送出結果) e=>end: 結束 st->op1->op2->op3->op4->op5->e ``` --- ### 一個Unit test的Demo,以BtRcnb為範例 ```react= //組件可以傳什麼 <BtRcnb prop="string" whenClick={() => console.log('callback')} basic> 更換飯店 </BtRcnb> //實際的html結構 <button className="bt_rcnb" onClick={[Function]}> 更換飯店 </button> ``` --- #### 如果改了共用組件要測幾次?(以票卷為例) ![](https://i.imgur.com/XV3R9JD.png) --- ### 用測試看懂程式的功能,節省維護的開發(時間)成本 ```javascript= //如果是Nightwatch.js可能長這樣 exports.command = function (browser) { browser .useCss() .openUrl(url) .setDestination() .setKindOptions() .setKeyword() .submit() .switchPage() .end() }; ``` --- ## *Unit and E2E Test Comparison* --- ***Unit test pros:*** - Tests run fast. - Test are precise and allow you to identify exact problems. ***Unit test cons:*** - Time-consuming to write tests for every aspect of your app. - Despite unit tests passing, the whole application may still not work. --- ***E2E test pros:*** - Can implicitly test many things at once. - E2E tests assure you that you have a working system. ***E2E test cons:*** - Slow to run — will often take 5 or 10 mins to run for one site. - Brittle — an inconsequential change, like changing a class, can bring down your entire E2E suite - Tests can't pinpoint the cause of failure --- ![](https://i.imgur.com/kKJfpo0.png =80%x) --- ### ***適合自動測試之應用場景*** - 長期維護的專案,提升可維護與功能穩定性 - 較穩定的區塊,可以替專案內較少改動卻又重要的地方增加測試 - 抽出來共用的部分,如共用組件 --- ## *如果有需求,較適合哪一種呢?* --- END ---