# 測試ｘ重構ｘ新技術 - 顏勝洲

{%hackmd rG6pzIawQKe5cHU4rycgYg %}

:::danger
R1 投影機中間兩台的對焦很糊，亮度也沒有旁邊兩台亮 QQ
:::

## 講師資料
> 國泰世華金控 ios 工程師
- 數據分析
- 資料工程
- 系統設計
- Mobile App

## Unit Test
> 不要想了，先做再說
> 感覺很重要，但是遲遲無法開始
基本的就是要做 Unit test
### 問題
- 不做unit test的原因
- 程式碼無法被測試
- 耦合度高，也不知道該怎做測試
- 開發功能都沒時間了，那有空再寫測試
- 做什麼都不知道，怎麼做 unit test

> **登入**
>
> 正確跳頁
> 失敗給錯誤訊息
> 失敗三

## 可被測試的程式碼
次要做什麼特別的，這個要怎麼做測試？
什麼程式碼可以被測試？
unit test 要測什麼？
- 測試output
- 測試物件狀態 Getter
透過 getter 來觀察屬性的變化
- 測試外部相依行為或動作
- 測試自己的程式是不是有觸發動作
- 觸發動作的內容是否正確
- 程式碼不含 UI 或 IDE 自動產生
- unit test 不測試 UI code，只測試邏輯 code
- 確認封閉環境
- 在哪跑，都要有相同的結果
- e.g. 網路存取會受到連線品質影響，
- 時間、亂數都要排除

### 降低耦合度

1. 隔離相依、繼承覆寫，自訂回傳內容
- 可以使用mock相關framework
- testing code, production code 需分離
- 需要的並不是相依的 code, 而是要他的情境而已
2. global variable, singleton 物件
- 可能被改變，所以造成意外的相依性
- 抽出global variable，另外在封閉環境做測試
- 直接當input 也可以，不要當global variable

### unit test 可以怎麼寫

- 正常路徑
- 錯誤路徑
- 資料排列
- 邊界條件: 想極端的測資
- 資料驅動: 根據產品特性，使用實際資料測試
- 測試缺陷(回歸測試): 哪邊出錯哪邊寫測試

> 需要長時間實作才有效果

### Cases

- case1: 好友列表的畫面
- 根據資料來源，製作 UI
- 好友有不同的狀態（如：邀請中），造成不同的畫面（資料顯示）
- 重複資料取新的值: 如何寫測試？
- 若資料來源有兩個，比較難一點 (取 updateTime 較新的 data)
- 要測試的內容：
- 資料比數
- 空資料
- 資料內容
- 錯誤格式（如塞信用資料到好友列表）
- case2: 外幣交易
- 試算
- 多少台幣可以買多少外幣
- 多少外幣可以買多少台幣
- 折線圖驗證資料正確性就可以了
- 測試內容
- 外幣匯率的**五捨六入**(銀行進位法)
- 字串處理: 千分位、小數點
- 買外幣、買目標外幣、賣外幣、etc.
- 測試方式採BDD
- 情境

## 如何說服做測試（ㄑㄩㄢˋㄕˊ）
- 怎麼寫最快 :thinking_face: ？
> 程式亂寫最快！！[name=講者]
- 為什麼要遵循開發框架
How → Why
協同開發,維護,軟體品質

## 測試的好處

$f(x) \{ return\ 2x + 1 \}, f(0.4) ? 1.8 2 1$

- 容易 code review: 代 null 會怎樣？出個對子對死他
- 相信你寫的東西，去驗證奇怪的情境
- 該程式碼的能力 $f(x) \{ return\ 2x + 1 \}, f(0.4) ? 1.8 2 1$
1.8 支援浮點數運算，浮點數輸出
2 支援浮點數運算，整數輸出
1 不支援浮點數運算，整數輸出
- 用法
- 功能
- 邊界值
- 避免修改時意外造成本來可以 work 的程式掛掉，以測試結果保證可以正常運作

## 重構
萬丈高樓平地起
想深入了解: 看書、看網友介紹

### 重構的目的

> ~~真正目的~~ 就是看不順眼，所以我要重構
> 需要符合某種架構，像是：MVC、MVVM、VIPER
> Legacy Code 都要變阿姨 (有時是重寫)
<!-- 阿姨是什麼梗？ 你們有看過code可以上小學的年紀 -->
<!-- 原來如此，受教了 -->
> 維護已經出問題，程式寫不下去了

> 最後最大的理由是為了測試

### 舉例：API 重構

1. API 是 APP 核心
2. 為了測試建立mock
3. 考量將來的擴充性

### 實作 adapter pattern

使用 plugin: `origin`, `new` , `mock`

1. 同時開發與重構
2. 避免一次翻新,部分功能release

#### Adapter Pattern 問題
Problems Check
- **重復的 code** 太多
- **維護成本**太高
- 沒時間做mock部分,更需要的是 **部分mock**

## 我們可以怎麼做？

1. 了解歷史、多點耐心與包容
> 現在都需要花多一點事件來確認為什麼？當時的用意? [name=講者]
2. 重新定義 Coding Style (my free style?)
> 需要根據產品特性做調整，不能一套用到底
> e.g. 銀行中有很多"代號"，長得像加密後一樣
> 編者：其實有的ERP資料庫都是代號[name=編者] e.g.: SP001 SP002
> 使用整個開發團隊最能接受的方式(方便溝通)
> 因為你所設計的名字可能不是真正的意思。所以還是代號比較好[name=講者]
3. 為了 5 年後想
用這個方式好？還是用那個方式好？設想五年後，你再看自己的程式碼。
從程式碼看見當年的想法
善用註解補充，讓後輩看到程式碼時更能了解當時情況

## 如何降低風險?
1. 寫測試（寫好寫滿）
2. 進行 pair programming (愈老愈好，愈資深愈好)
3. release 針對 **部分使用者**
小技巧：用 UserID 最末碼來區分，挑 1 個數字發布新版本，其他的還是原版本，這樣就有 10% 的測試樣本了

> ### 當重構變成日常就沒有重構了 ~應該是每次開發都重構？才是日常。特別找一天不算日常，算重構日。~
例如：10 天挑 2 天來做重構

## 新技術 New Technology
> 業配囉
> 因為我是銀行派來的～所以還是要講一些銀行的東西～ [name=講者]

- 後端驗證（原本）
- 送帳號密碼給後端做驗證
- [FIDO](https://fidoalliance.org/what-is-fido/) 登入（FIDO 是生物驗證標準）
- Server <-> FIDO server <-> Frontend

> 本來就 **應該要有的東西**
這個世代預期本來就應該要有的東西就要把它做出來

###### tags: `MOPCON 2020`