一個完整的開源庫必須包含

• 文檔
• 好的編譯需求
• 規範
• 測試
• 持續集成

小明說:在前面幾個章節我們有提過"沒有單元測試的庫，就代表有一定的風險"
小華說: 為甚麼呢?
小明說:你想想喔，如果今天一個庫有局部的修改，但是要怎麼知道 修改完，所有的function都沒有壞呢
小華說 : 我猜猜，一定是測試

單元測試

單元測試能夠保證每次交付都是有質量保證的。而開源庫除了需要質量高的代碼，還需要部段的更新優化，為了避免更新後所衍生的問題，撰寫單元測試是對開發者的最佳選擇，更是對使用者的保障。

單元測試的單位？

• 以 function 為最小單位，程式裡每個單一行為，可稱為一個單元。
• 以 function 為最小單位
• 以 function 為最小單位
• 以 function 為最小單位，很重要，就像網頁性能是以單頁為單位。

單元測試對開發者的好處

• 讓開發者可以更專注在邏輯與代碼，不用花過多精力去維護各種不可控的場景和數據依賴。
• 產生穩定可靠的測試結果，包含通過和失敗

這裡先稍微介紹兩個常被提到的單元測試面向

• BDD
• TDD

TDD （Test-driven development）測試驅動開發

• 是一種開發的流程。許多專案在開發時，通常會邊寫程式邊寫測試，或是先寫程式後寫測試，或是寫程式寫測試。
  開發者寫出測試時，就可以瞭解這一個元件/方法最後會怎麼使用，同時也釐清程式該怎麼設計。整個開發流程會在單元測試、撰寫程式、重構三者間不斷循環，是一種有效提升程式品質的開發方法，所以通常是工程師所負責。

• 圖片來自 TDD Vs BDD – Analyze The Differences With Examples (https://www.softwaretestinghelp.com/tdd-vs-bdd/)

BDD （Behavior-driven development）行為驅動開發

• BDD 是 TDD 的進化版，除了一樣先寫測試再實作外，還要先寫規格，但是這份規格並不是單純的敘述軟體的功能，而是這份規格，是一份「可以執行的規格」，也就是其程式語法描述其極接近日常口語，相當簡單易懂，也可以執行。也就是說比起 TDD ，BDD 更可以讓非技術人員一起參與討論，能讓使用者、測試人員與開發人員，可以用一樣的方式來描述與了解需求。

• 圖片引用自 hybrid-development-with-tdd-ddd-bdd (https://dzone.com/articles/hybrid-development-with-tdd-ddd-bdd)

總結

也就是說TDD通常用於工程師開發階段，藉由在開發前先寫測試，以確保程式碼品質與符合需求的結果。

而BDD偏向整體的系統功能與業務邏輯的自動化測試，主要是減少使用者、測試人員與開發人員的溝通成本。

參考資料:

• 初探前端 Unit Test(https://w3c.hexschool.com/blog/aead1e7e)
• 8102年如何寫一個現代的JavaScript庫(https://juejin.im/post/6844903687819640845)
• JavaScript庫架構實戰(https://codertw.com/%E7%A8%8B%E5%BC%8F%E8%AA%9E%E8%A8%80/698450/)