可測試的 JavaScript Ch0、Ch1

有一次聽到「先寫測試再寫程式」覺得太酷了8～就很想成為很會寫測試的人（也就會順便變成很會寫程式！？）。前陣子買了這本書，看了一半覺得有點難XD
所以回頭再讀一次、寫下筆記，更確定自己有讀進去🐣
（前言跟第一章完全沒有程式的部分，讚！）

前言

既有的程式碼？

《Work Effectively with Legacy Code》的作者定義既有的程式碼(legacy code)為沒有測試的程式碼。當這些從別處來到我們手中，或者從我們手中去到其他開發人員手上時，需要新增功能、除錯、或是為它撰寫測試時，很多人會選擇整個重寫以防改A壞B。而避免寫出難以維護的既有的程式碼的最佳方法就是好好寫測試。

避免造成災難的原因：高複雜度、緊實耦合

寫程式的時候如果能隨時注意到是否具有可測試性(testability)，就更容易能寫出相對應的測試程式。而這樣的程式也相對更容易保持低複雜度、鬆散耦合的狀態。

什麼是可測試(testable)的程式？就是第一章的內容了：

第一章：可測試的 JavaScript

既有的軟體開發流程

軟體開發流程是一套可以重複實行的作業流程，透過標準化與規則話這些流程來改善開發人員的程式碼品質——無臭蟲、無缺失。（但開發人員的個人意志也是很重要的XD)

敏捷開發 Agile Development

因應瀑布式(waterfall model)而生。敏捷開發把任務切成較小的單位、縮短運作週期，讓每個相關人員都一直有事可以做、人員間的合作也會更密切。

瀑布式：依序執行每個獨立、不平行的開發流程，例如：先寫規格→寫程式→做測試→部署。

敏捷測試本身沒有規範怎麼寫程式、也不一定會提升開發速度/品質，但比起瀑布式開發，它擁有更大的彈性，在需求變更時能更快將其納入開發流程中。

測試驅動開發 Test-Driven Development(TDD)

先寫測試再開始開發。TDD也是避免前言中提到的既有的程式碼的最好方法。

行為驅動開發 Behavior-Driven Development(BDD)

建立在TDD之上，透過使用者情境（user stories）來定義程式的規格、期望的結果。

測試「即」驅動開發 Test-While-Driven Development(TWDD)

作者提出的軟體開發做法，開發與測試幾乎同時完成：寫一部分開發、隨後補上測試；或者寫一些測試後馬上寫上程式。

小結

無論是使用何種方式，研究指出測試的數量與程式的品質成正比——無論是在開發前、中、後，能夠多寫一點測試都是絕對無害的。

---

可測試的程式碼

就是容易做測試的程式碼，而這樣的程式碼通常也容易被維護、容易被瞭解——好懂好 debug！

可維護的程式碼：不要一大堆亂七八糟寫在一起！

• 短小
• 獨立

可了解的程式碼

• 完整的註解
• 有意義的命名
• 前後一致的程式碼慣例

---

測試的種類

單元測試（unit testing）

以程式中最小的邏輯單位寫測試程式，來驗證邏輯是否正確，通常用在測試 pure function：輸入 input 是否有達到預期中的 output。

整合測試（integration testing）

測試整合多個邏輯下的情況，確保模組與模組之間的互動行為是正常的。以前端來說的話可能是一個 React Component 中的各種行為（跟DOM互動、串接API等等）。

效能與負載測試（performance and loading testing）

確認程式執行是否符合規格

端對端測試（End-to-End test）

這是作者沒有提到的部分，E2E test可以撰寫程式來模擬使用者操作網頁的流程（就是把人工的部分轉變成程式執行）。