既然要介紹 RSpec，就不得不提到測試的種類，根據下圖可以將測試的種類分為四大類：

Unit Tests

專注於測試程式之間每個功能在切碎後的程式碼，就像一個 Class / 一個方法 / 一個物件 / 一個模組 etc.

每一個小單元被單獨做測試，不受到任何干擾或是其他有關係的程式碼影響，專注在設定的小目標上面，確保測試成功。

這時還是非常初期的測試，所以才會被放在金字塔的底部，代表整個測試的基底。

這時候的測試非常好寫，而且執行速度又快，是最快樂的時候！可以一直看到綠燈亮起，覺得人生很美好

Integration Tests

這時候的測試比 Unit Test 稍微複雜了一些，需要整合一項稍微完整的功能，記住，這時候的功能也不過是整個應用程式的小螺絲而已，可以把剛剛介紹的 Unit Test 想像成製作螺絲的原物料。

這時候的整合測試的目的就在於檢驗這些原物料到底組裝起來能不能變成一個小螺絲，有時候每個 Unit Test 都能夠通過，但真正的組裝起來卻變成一個漢堡？這就和我們一開始的需求有出入了。

這只是第二層，來確保 Unit Test 的方向沒有錯，合在一起也能夠滿足需求

UI 又稱使用者介面 ( User Interface )

這時候已經是要測試所有功能的整合，以及測試整個系統的運作流暢度和互動效果。

所以這邊可以叫做 UI Tests 的原因就在於，專注的點更廣，在於整個應用程式的使用效果，畫面中的互動，操作上的效率 etc.

撰寫 E2E 的測試難度較高，執行的速度也很慢，這次的鐵人賽還是以 Unit Test 為主，希望專注在基礎的測試上面，畢竟要蓋成金字塔，也是需要先打地基的

這時候的應用程式已經開發到一定的完成度，只剩下手動測試的部分！

對於手動測試我想也不需要解釋太多！

還是要根據事先完成的測試 SOP 規範，不是亂按一通就是手動測試

來說說手動測試的優點好了！

手動測試基本上是一定會發生的，~~就算你什麼測試都沒有寫~~

因為那出自於人性，你永遠會去試著執行你寫出來的程式，而有些 Bug 確實不會被測試框架給捕捉到，它可能很細節，或是使用起來很慢等等

這些都是開發工具沒辦法告訴你的，所以手動測試雖然在最上層，但卻是我覺得最重要的一個環節之一。

今天稍微介紹了一下測試的種類，看著圖片來閱讀文章，應該也能感受到一股積沙成塔的感覺，為了提升應用程式的穩定性，測試是絕對不可少的一環！

但每一個專案的開發時程都不一樣，不一定有時間遵循這張圖片進行測試，這時候就要稍微做取捨來決定該使用哪些測試，而測試又該要用在哪個功能上面才能讓 Bug 發生時不會無處可找！