DAY27 Unit test 會挑戰你的邏輯

16th鐵人賽

華生

團隊好想工作室 v8.0

2024-10-11 14:36:22

145 瀏覽

分享至

Who the hell are you

前言

在寫程式語言時，我們需要大量的邏輯，但你寫的邏輯真的是通順的嗎？這時 Unit Testing（單元測試）出現了！它的功用在於檢查你所寫的程式碼是否正確，以避免 BUG，確保程式碼品質。

之所以稱為「單元測試」，是因為它的目的是針對應用程式中的「單一單元」進行測試。在軟體開發中，「單元」通常指的是程式碼中的最小功能單元，例如函數、方法或類別。單元測試的核心概念是將應用程式劃分為這些小的、可獨立測試的單元，並確保每個單元能夠在隔離的環境下正確運作。

Fun fact

你知道嗎？早在 1963 年，NASA 的水星計畫就已經運用到單元測試！

麻瓜解釋

今天小銘和小華在用樂低積木（程式碼）搭建腹愁者聯盟大廈。大家一開始都急於看到最終結果，所以照著說明書（設計稿）進行。前期的步驟（HTML、CSS）還算順利，因為只是骨架和視覺上的需求。然而，當進展到機關功能（JS）時，問題開始出現了。儘管他們試圖按照自己的邏輯拼接積木，但有一塊怎麼拼都不正確，導致大廈的內部機關無法正常運作。

當小銘和小華做到電梯機關時，由於缺乏詳細說明書，他們只能發揮自己的創意來組裝（撰寫邏輯），但難免會出錯。這時小嘉不知道從哪裡蹦出來，並用她那奈米的音量建議他們使用 Unit Testing。它的主要功能是針對單一區塊進行邏輯測試，檢查拼接方法是否達到他們期望的效果，同時也確保不會影響後續的機關工程。

在使用 Unit Testing 後，他們終於找到正確的拼接方法，順利繼續施工，直到完成腹愁者聯盟大廈。

歷史

單元測試作為一種測試大型軟體系統中小部分的原則，可以追溯到軟體工程的早期。1956 年 6 月，H.D. Benington 在美國海軍的「數位電腦高級程式設計方法研討會」上介紹了 SAGE 專案及其基於規範的編程方法，這種方法在編碼階段後進行「參數測試」，用來驗證子程序是否符合規範，接著是對組件進行的「組裝測試」。

到了 1964 年，類似的方法被應用於水星計畫的軟體中，不同的程式設計師開發的各個單元在整合前會經歷「單元測試」。到 1969 年，測試方法變得更為結構化，包含單元測試、組件測試和整合測試，這些測試旨在驗證單獨編寫的部分，並逐步組裝成更大的功能塊。一些公共標準如 MIL-STD-483 和 MIL-STD-490 在 60 年代末被採用，進一步促進了單元測試在大型專案中的廣泛應用，而單元測試技術也不斷進步。