若要進行DevOps，單元測試一定是必經歷程，因為在進行CI的時候會進行線上測試，CI測試會測的其中一環就是單元測試，若CI測試通過系統才會幫你部屬到主機上。
在此篇文首先我會介紹甚麼是DevOps，但在了解DevOps前，我會先講一個實際的情境，讓大家了解到DevOps雖然技術成分很重要，但比技術更重要的是團隊之間的溝通與DevOps文化的養成，聽起來很像屁話，來講個實際的情境。
上方圖片是從延伸閱讀：Can I Use XXX?的網站擷取出來的，該網站可以查詢指定技術目前不支援的瀏覽器，像我就選了前端網頁排版利器flex來找尋，發現有好多不支援的瀏覽器版本 (綠色是有支援，紅色是沒有支援，棕色是部分支援)。
大家可以想像如果我們前端工程師通過前人寫好的測試，該測試是傳承下來的可以保證其可靠性，QA人員在進行Acceptance test時標準若是寫通過IE瀏覽器測試，但該標準可能忽略了版本的因素，造成實際上現實客戶端出錯，這時就要開始Debug了，但前端工程師這邊會覺得我測試明明都通過了你怎麼會覺得是我們的問題，QA這邊可能會覺得是不是你們程式寫得有問題，最後經歷了無數開會的日子才發現是瀏覽器版本的問題，若是有建立一個團隊有效溝通的管道就能避免Acceptance test標準寫的不完善的情況發生，所以我才說DevOps其實最強調的就是組織DevOps的文化養成，技術是其次，溝通才是真正要去重視的地方~在講完屁話的部分XD，那接下來繼續往比較實務的地方邁進，先來介紹甚麼是DevOps吧!
DevOps定義
通過建立一種可以快速、頻繁和更可靠地建構、測試和發布軟件的文化和環境，然後讓產品持續產生價值。
正如上面所述，DevOps是一門注重敏捷思維的學問，工程師們時間有限，透過自動測試與自動部屬，能讓工程師不必花過多的心思於日常維運，自動化省去的時間更可以拿來學習新技術，讓專案效能越來越頂! 而本文重點是在單元測試，所以會對DevOps中的TEST進行更深入的介紹~ 延伸閱讀：Day1 Why DevOps?
測試有哪些種類?
那就從金字塔最底層往上吧bottom-up
- 單元測試 (unit test)：單元測試是對軟體組成單元進行測試，是檢驗軟體基本組成單位的正確性，測試的物件是軟體設計的最小單位：函式，通常是一個函式對應一個測試，並且使用假資料測試不同狀況下功能使用情況。
- 整合測試 (integration test)：測試多個元件串聯之後可不可以正常運作。整合測試的物件是已經經過單元測試的模組。
- 系統測試 (system test)：驗證整個軟體系統在不同環境下的功能、性能、安全性、可靠性。
- 驗收測試 (acceptance test)：以使用者的觀點去進行測試，確保產品符合使用者的需求。
在了解各式各樣的測試過後，我們將更深入地探討Unit Test!
單元測試的意義
先來定義甚麼是單元測試!
保證程式碼的品質，減少潛在的錯誤。
我們可以說單元測試是為了讓程式在上線正式環境前提早發現問題並提出修正，她保證了每個函式執行結果是正確的、保證寫出來的程式碼效能是好的，我們可以說「 通過所有測試，代表了專案能正常運作!」
以單元測試為例，自動測試+自動佈署實際情況
還記得我們在一開始有提到導入自動測試+自動佈署可以讓工程師們工作更有效率嗎?
既然都講到了單元測試，這邊要特別提一下單元測試與自動測試+自動佈署的關聯。
由左至右，第一張圖：就是我們自身使用者發送push請求推送至程式碼託管平台
第二張圖：當使用者寫好程式碼後會將程式碼上傳至程式碼託管平台進行備份，方便後續人員進行版本控制。知名的程式碼託管平台有GitHub、Gitea、GitLab。
第三張圖：當推上程式碼託管平台後就會觸發持續整合服務的腳本，該腳本會去呼叫持續整合平台服務(像drone就是自己開一個server)，而持續整合包含了持續交付，與持續測試，我把這兩個概念濃縮成自動測試，最常見的自動測試所指的測試一般就是指本文的主軸【單元測試】，知名的持續整合服務平台有DRONE、Jenkins、Github、Action。
第四張圖：最後產品經測試後一切ok終於可以上線了，透過持續整合服務的腳本內容，持續整合服務平台可以因應各種不同需求以各種花式部屬的方式部屬至雲端伺服器上。知名的程式碼託管平台有AWS、Azure，當然你如果想架在自己家的伺服器也可以。
觸發線上測試服務腳本
- 可以在drone腳本中指定當推上哪隻分支時，會觸發持續整合平台服務。
程式碼託管平台查看測試是否通過
- 觸發持續整合平台服務會進行單元測試，如果通過單元測試持續整合平台服務才會把你的程式碼自動建構部屬並推上prodution伺服器。
Clean Code F.I.R.S.T 測試原則
在撰寫單元測試時呢可以參考Clean Code中的F.I.R.S.T 測試原則來進行撰寫，Clean Code指的是易於閱讀、理解和維護的程式碼軟體工程的實踐方式，它是由一群coding很厲害的人聚集起來討論程式碼該怎麼寫才是好的程式碼，但他就只是一種軟體工程的實踐方式，你不去實踐其實程式一樣還是能跑，但是品質就是會有差異，沒有維持良好的Clean Code會讓後續維護人員很難維護。Clean Code其實是一本書，有興趣可以去借來看看，以下將介紹FIRST原則是甚麼? 延伸閱讀：第 9 章 單元測試| Clean Code
Fast：測試執行的速度要越快越好，測試如果跑得不夠快，就不會讓人想常常跑。
Independent：不要讓一個測試高度相依其他測試，測試的失敗會影響其他測試也跟著失敗，會很難找出問題癥結點。
Repeatable：測試應該要可以在任何環境中重複執行，減少因環境因素而產生測試失敗的問題。
Self-validating：不管是測試成功或失敗。測試程式應該要輸出布林值，ok或者fail。
Timely：撰寫測試要及時，最好是在寫產品程式前先寫(TDD的概念)。
測試之理論面重點回顧
- DevOps是什麼?
- 單元測試的意義?
- 自動測試+自動部屬實際使用場景
- Clean Code的測試規範
總結
介紹完DevOps與單元測試的理論基礎，下一篇我會帶大家了解若要用登入的功能來寫單元測試究竟要怎麼規劃，還會介紹程式覆蓋率是甚麼以及可以交差給主管的實用報告-覆蓋率測試報告如何建立呢?