昨天有提到，概念上是要開發人員每次測試的時候都自己建環境。但相信維運人員幫開發人員建一個專用的伺服器後，開發人員可能會為了 compile .Sass 檔，所以裝一個 Ruby + Node；為了要切換版本，又裝了 rvm 和 nvm，還裝了 gulp 之類的 global 套件，結果就開不了機了。相信維運人員很難照顧到開發人員求新求變的需求。

CI 講了這麼久，大家也許會覺得跟維運人員好像沒什麼太大關係，因為幾乎都環繞在測試上。今天來聊聊 DevOps 的其中一半：開發如何考慮維運。

今天討論主題很重要，但也很容易被忽略的－－測試範圍。一份軟體會有許多不同種類的測試，它們會有測試可以確保的部分，而這些部分跟測試的範圍是有直接關係的。因此，知道測試的範圍，就知道確保的部分。

昨天提到了 Test Double 的其中兩個類型，分別是 Dummy Object 與 Stub。在實務上，這兩個已經非常好用了，今天繼續把剩下三個類型說明，聽完應該就能應付九成的依賴問題了。

細心一點的朋友們，或許會發現昨天有個細節沒討論到：「依賴的元件如果因為某些原因而無法初始化的話，該怎麼辦？」，這其實是一個常發生的問題，只是常常用不同的形式呈現。

廣義的說，當測試有包含多個單元時，就算是整合測試了。即使單元測試完整，各單元功能也正常，但組合在一起時，通常還是會發生許多莫名的問題。這時先不要想哪個單元沒寫好，而是先摻在一起做整合測試比較好

有句話是這麼說的：「懶惰是工程師的美德」。因為懶，所以才會寫出各式各樣強大的工具。是的，今天的標題就是我們的目標。

如果依層級分類的話，相對最底層的 Testing 就稱之為 Unit Testing，中文稱之為「單元測試」。

在我第一次要做 CI 時，是毫無方向不知道該先做什麼好。那今天要講的是，這五天常常提起最實際要做的，但也還沒深入討論的細節－－驗證。

前四天跟大家聊很多觀念與思考一些議題，今天要來聊聊 CI 該怎麼開始了！