# **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
---