對於一開始要寫測試，我其實最困惑的就是我究竟要從哪一種下手，就我的理解測試的種類可以分成：

測試的種類

根據測試的對象以及作用範圍來分類，主要可以區分為以下幾種：

1. 單元測試 (Unit Test):
   • 對象：單一函數、方法或類別。
   • 目的：確保代碼的最小單位運作正確。
2. 功能測試 (Feature Test):
   • 對象：特定功能或用戶故事。
   • 目的：模擬用戶行為，驗證特定功能是否運作正確。
3. 整合測試 (Integration Test):
   • 對象：多個單元、模組或元件之間的交互。
   • 目的：確保當不同的代碼部分或系統整合在一起時，它們可以正常工作。
4. 界面測試 (UI Test):
   • 對象：軟件的用戶界面和互動。
   • 目的：確保用戶界面元素如按鈕、表單等正確運作，並提供良好的用戶體驗。

Feature test

當你的測試對象是一個功能的時候，就是寫功能測試，我覺得這個功能測試的功能，主要在你今天開發東西是什麼，比如說我自己是在開發寶可夢API，我的功能就是API的功能，也就是我實際去對他發請求，然後他結果符不符合我預期。

• 那為什麼不用postman測就好？

  這是我一開始也有的一點小疑問，我覺得關鍵在於：

  • 效率

    如果你有把測試寫的完整，考慮到很多情況，他就可以一個指令測完所有你預想的情況(在你有寫好的狀況下）。

  • 幫助系統擴展後的整體確認

    • 如果今天你的整個專案需要增加新功能，自動化測試或許可以讓你快速的觀察原本的功能是否有受到影響。
    • 但這裡如果是有動到原本的代碼或是修改功能，其實有時候也要判斷測試是否要修改或重寫，所以我還是認為寫測試這件事情還是要根據當下情況去評估，畢竟要花的時間也是不少。

Unit test

單元測試也是我一開始容易跟feature test混淆的部分：

• 怎樣叫做一個單元？

  通常指的是軟體中的最小可測試部分。

  • 那什麼叫做最小可測試部分？

    我認為一個可測試對象最基本的要有輸入跟輸出，我才可以根據我輸入的內容有所期待並根據實際結果做比較。

    比如：

    function add(a,b){
    	return a+b;
    }
    

    像這樣簡單的邏輯有輸入輸出，他可能也在一個API裡面的一小部分，我覺得這個就可以寫單元測試

• 模擬

  我覺得單元測試也有一個很重要的概念那就是模擬：

  • 什麼是模擬？

    也就是當你今天的單元測試有牽涉到外部因素，將這些外部因素用模擬的而不要實際去對他做操作，比如你今天這個單元最後是新增一筆資料到資料庫，那這個動作就用模擬的，不要實際去存。

    • 為什麼要模擬？

      • 減少干擾

        今天的對象如果是在這個最小單元，那我們應該聚焦在這部分，比如說：

        今天你的最小單元對資料庫操作，然後資料庫出問題了，或許錯誤會跟你說是資料庫的問題，但這就不是我們個最小單元的問題，會混淆我們的判斷。

      • 效率

        速度：模擬的操作，如虛假的資料庫查詢、模擬的網路請求，通常遠比真實的操作來得快。這樣可以使得測試在短時間內完成，對於大型專案特別有幫助。

        避免外部資源消耗：如果每次測試都需要真正地連接資料庫或外部API，會消耗大量的資源。模擬則可以避免這些不必要的外部連接，從而節省資源。

小結語

• 目前覺得對於這些測試的感受還不是很深，雖然自動化測試一定要他重要的地方，但在你專案小的時候，都還不太會體現他的優勢，但就是希望先理解概念和基本的寫法，希望對外來真正需要用到的時候有幫助。
• 至於實際feature test的寫法以及單元測試的模擬，我想我下一篇再來分享我是如何寫的。