既然被強迫推銷了防禦魔法,來問看看到底是指什麼好了。
「所以說防禦魔法到底是指?」
「那就要從很久很久以前開始說起了…. 在很久很久以前有個遠得要命王國,住著一群魔法師,他們共同建築了複雜精密運算的魔法陣,但難免會有疏失的時候,這時候偉大的防禦魔法誕生了,防禦魔法的歷史在 1XXX 年 (下略一百字….」
「暫停一下!所以防禦魔法是可以抵禦外敵入侵的意思囉?」
「不是耶!」
「等等等,那它拿來防禦誰?」
「自己!」
「防自己,防自己做什麼!?」
看著綠繡眼型態的艾草一臉悲傷的樣子,我把還想質疑的話默默的吞了進去,緩緩地開口道:
「阿不然,你就講解看看好了啦!」
針對程式碼最小單位,如 function 去進行測試,通常撰寫者為工程師,擁有幾個特點:
單元測試可以測試一小段程式碼或一個流程的功能功能,以一個表單為例:一小段程式碼可能會是使用者是否有輸入值的判斷,而一整個流程可能涵蓋使用者填寫表單到送出。
但要注意單元測試並不會有外部依賴項,如:直接打 API 等待回傳值等,所以並不會因為回傳值而導致測試的結果產生變化。
在單元測試失敗時,因為是最小的測試單位,也很容易找出問題點,也因此單元測試相較於其他測試更好維護。
整合測試通常用於測試幾個元件間的交互作用,及幾個元件協作後是否會有預期以外的失誤。
整合測試與單元測試的界定很模糊,不同的是整合測試會有外部環境依賴項,引用 WadeHuang 作者的 探討單元測試和整合測試的涵蓋範圍 文章內容如下:
測試案例成為整合測試的關鍵點是:測試案例是否包含與外部環境交互的邏輯,如時間、Session、Cookie、資料庫,硬體,網路等等不受程式控制的因素。
簡單來說,若測試案例無與外部環境交互的邏輯,則可以將測試案例視為單元測試
端對端測試基本上是會花最多時間及成本的測試,而大部分的端對端測試是由人工去進行的。
將自己當成用戶,並由輸入網址開始,進行網站的一系列操作行為,確保網站的整體功能、流程皆能順利的運行,即為端對端測試。
一開始在學習區別單元測試、整合測試時卡住蠻久的,後來通過作者 WadeHuang: 探討單元測試和整合測試的涵蓋範圍 及作者 Jack : Unit Test 實踐守則系列分享為我解答了疑惑,原來最主要判斷的依據就在於有沒有外部依賴項:如資料庫或第三方資源等,如果沒有的情況下,不論是測試一小段程式碼或一小段行為,都還涵蓋在單元測試的範圍內。
https://ithelp.ithome.com.tw/articles/10229734
https://yu-jack.github.io/2020/09/14/unit-test-best-practice-part-1/
https://zh-hant.reactjs.org/docs/testing.html
https://www.softwaretestinghelp.com/the-difference-between-unit-integration-and-functional-testing/
https://blog.miniasp.com/post/2019/02/18/Unit-testing-Integration-testing-e2e-testing