Ch1 可測試的 JavaScript 程式（Testable JavaScript）| 可測試的 JavaScript (Testable JavaScript) 閱讀筆記

流程 vs 品質

一直以來，組織試圖利用不同的工作流程來改善開發人員產出的程式碼品質，以下列舉一些知名的解法

• Agile：讓每個階段能平行執行，避免等待。其秘訣是將每個階段的時間切小，讓運作週期變短，這樣就能有足夠的應變能力來適應高度變化的需求。
• TDD：先寫測試再做開發。
• BDD：利用使用者情境來定義測試規格與預期的結果。
• TWDD：開發與測試幾乎同時間完成 - 先開發一部份的功能，然後立刻補上測試；或是先寫一小部份的測試，然後開發這一部份的功能。以這樣的方式進行專案，直到功能完整完成。

注意

• 研究指出，程式碼的品質與測試多寡有關，測試愈多，品質愈好；而程式碼的品質與流程並無關聯。也就是說，無論遵循哪樣的流程，只要測試程式的覆蓋率夠高、測試案例夠多，程式碼的品質必然提高。
• 測試要寫什麼，可以跟 QA 拿測試規格，依據這樣測試規格撰寫出來的就是最低標準的測試程式。

為什麼要寫可測試的程式？

以下同義

可測試 === 好維護 === 好理解 === 容易解 bug。

怎樣的程式碼，算是可測試的程式碼？

• 程式碼少：只做一件事情，目的明確
• 不複雜 (complexity)：好理解
• 有註解
• 鬆散耦合 (loosely coupled) 或 最小相依性 (dependencies) 或獨立 (isolatable)，意即不影響其他函式或功能

不同的測試有不同的目的

• 單元測試：單一功能或元件的測試是否合理
• 整合測試：測試整理結合的運作是否合理
• 效能測試或負載測試：確認系統是否符合規格