中秋佳節連假，看著一堆人出遊的新聞，然而還是有一大群熱血的夥伴，在連假中一起在線上進行了【#針對遺留代碼加入單元測試的藝術】以及【#極速開發】的培訓。
這是第一次採線上直播的進行方式，在上課前因為之前有錄 Classic TDD by Example 無限次觀看的影音課程的經驗，比較能掌握在螢幕上該怎麼解說、標記、highlight 重點。
而這次課前也跟同事和夥伴們事先練習過，如何用 zoom 來安排互動、討論、上課下課之間流暢度的配合，所以都還蠻順利的。
唯一就是開了6個 IDE 再加上 zoom 的直播當下，memory 跟 cpu 在 live coding 過程中，跑單元測試需要等待的時間拉長了，甚至 6 個 IDE 時 intellisense 出來的速度跟不上我的手速（後來關到剩下4個）
陪家人團聚很重要，讓自己進步也很重要，疫情肆虐下要恢復過去的生活已經幾乎不可能了，但工作機會卻因此越來越險峻，怎麼投資自己，怎麼讓自己更加熟悉線上/遠端的協作，還是很重要的。
感謝陪伴我第一次正式線上直播課的所有學員，謝謝你們即使在遠端，仍積極參與、發問，還有課後的練習。
※ 極速開發課上完當晚，就有學員錄好第一版練習影片找我 review 了，今天是第二天，已經有六位同學交了第一版作業。看到大家都這麼熱血，我也跟著沸騰起來了。
投資自己不嫌晚，但最怕沒跨出第一步，你不需要一開始就很強，但你需要開始才能變強。
也謝謝好夥伴 Cash Wu Geek 在線上幫忙顧前顧後，有你的協助，讓兩天課得以進行地更順利完整。
後 端 單元測試 在 Re: [請益] 測試程式問題- 看板Soft_Job - 批踢踢實業坊 的美食出口停車場
※ 引述《VFCanisLupus (CanisLupus)》之銘言：
: 請教一下版上前輩測試方面的問題
: 我們公司的產品是有著微服務架構的後端服務，最近想導入測試但是在開會時對於測試的方
: 式與方向跟夥伴們有些意見分歧，想聽聽版上前輩的意見。
: 1. 單元測試： 我的想法是單元測試是針對每個method做測試目的是希望每個method都能符
: 合預期不會改a錯b. 單元測試也不應該與外部相依，比如說資料庫應該都用mock DAO 的方
: 式來測試。
: 不過夥伴認為我們應該也要連sql都一起測試，不然我怎麼知道sql是否正確？(意見不同1)
: ，寫測試程式很容易因為測試案例不好而導致測試測的不完全，寫這測試會很沒意義（意見
: 不同2）
1. 個人偏好做法：DAO 層的任務是跟 DB 溝通，這裡的 unit test 我會測 SQL。
商務層應該只關心商務邏輯，直接 mock DAO 層。這是來自單一責任原則的啟發。
2. 你可以找一下你們使用的語言有沒有用來跑單元測試的 embeedded db/mongo/redis。
如果沒有的話可以考慮跑單元測試時用 docker 跑 db 起來測試。
3. 發現自己測試沒寫好，進而反省改善就是種意義。當然，這僅止於懂的反省自身的
工程師。
: 2. 整合測試： 老闆認為有單元測試只不過方便日後重構而已，還不如來寫整合測試（打HT
: TP request 測試） （意見不同3）
unit test 除了驗證程式行為還有其他好處：
1. 未來改邏輯或加 feature 你會比較有勇氣。你可以想像你每次想修改一段邏輯，
都要等整合測試跑個十幾分鐘才能得到反饋，是我都沒勇氣改了。
2. 好測試的 code 通常程式架構會比較好改：為了讓程式好測/可測，你會讓程式
耦合性降低，讓功能責任單一，甚至你會更明確知道 DI 的重要性。
3. 有測試的 code 等於一份該 component 的使用教學，像我就會從前人的測試 code
學業務邏輯。
4. 整合測試涵蓋範圍太廣，一個測試失敗可能是網路/系統/設定/程式碼任何一個地方
出問題；反觀單元測試執行速度快，又可以快速定位問題。好單元，不測嗎？
以上個人不負責任經驗談。
: 我的想法是
: 意見1: 可以延到整合測試測，因為單元測試目的是在於驗證程式碼有無如預期進行，且應
: 該要可以快速測試驗證。
: 意見2: 可以用測試覆蓋率為參考依據
: 意見3：因為整合測試無法有效提昇覆蓋率，且有環境等因素考量，也跟業務邏輯牽扯 （塞
: 資料順序等等），反而門檻更高。
: 不知道版上前輩有什麼其他想法嗎？
: 或者其實我觀念有錯誤？
: 謝謝
: --
: ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.242.203.105 (臺灣)
: ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1563110242.A.161.html
: 推 jack0204: 單元測試也能測SQL阿，有的框架支援記憶體儲存ORM 07/14 21:42
: 是指記憶體型的db嗎？ 但我們用的是mybatis這種object mapping 的框架，用的是MySQL
: 怕有些MySQL 特有的語法會不支援， 再來我們還有其他微服務用到mongodb and redis
: 推 art1: 測得不完全也比完全不測好 07/14 21:43
: 是沒錯
: → jack0204: 不然就是建一個stage環境配migrate執行完整測試 07/14 21:43
: → jack0204: 如果測試案例不好那就把他寫到好阿，不然寫爽的膩? 07/14 21:44
: 是阿 不過現況是公司有一半的成員是junior 可能要費點心思了
: → jack0204: 整合測試是因為測一整次很花時間，單元測試就快多了 07/14 21:45
: 推 jack0204: 單元(純邏輯)/功能(假DB)/整合測試看你們想做到哪一步 07/14 21:51
: → pigcat1315: 沒SDET部門就坐單元測試就好 不然測試的龐大你寫不完 07/14 21:55
: 我也這樣認為，但老闆認為 整合測試是要給工程師寫的，不過在資源有限的公司裡確實也
: 是這樣就是了
: 推 sojoasd: 小的淺短的建議：專案還在開發階段時，寫測試DB比較好， 07/14 22:04
: → sojoasd: 因爲這時期schema可能常常變動，當然就是比較麻煩。另外 07/14 22:04
: → sojoasd: 串接微服務可能改成其他排程task定時執行測試會比較好 07/14 22:04
: → sharku: 單元測試也可以測SQL 看你後端用什麼框架而定 07/14 22:08
: 單元測試也可以測試sql嗎 小弟去研究看看
: ※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:47:00
: ※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:50:39
: 推 supernow: 我們這邊單元測試不直接打db，是直接mock掉只驗sql語法 07/14 22:52
: → supernow: ，跟你的想法一樣，另外在整合測試裡才實際連db 07/14 22:52
: ※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:53:39
: ※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:55:13
: 推 supernow: 至於測試案例寫不好這只能靠code review多電幾次才能改 07/14 22:55
: → supernow: 善 07/14 22:55
: 了解 感謝回覆
: ※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:57:20
: ※ 編輯: VFCanisLupus (27.242.203.105 臺灣), 07/14/2019 22:58:05
: 推 sharku: 單元測試的DB只在執行時產生 測試完後刪除 不連到實體DB 07/14 23:15
: → pass78: h2 07/14 23:20
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 49.215.240.201 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1563121021.A.0F5.html
... <看更多>