Ch28: 測試邊界

TESTS AS SYSTEM COMPONENTS

• 測試也是系統的一部份，是特別的存在
• 測試的本質 -> 很重要也不重要
  • 依賴於被測試的程式
  • 可以看作最外圈的程式，沒有人依賴於他
  • 可以獨立部署，大部分被部署在測試環境，而不是生產環境
  • 對用戶或運行中的程式來說不重要，但對系統來說很重要

DESIGN FOR TESTABILITY

Fragile Tests Problem

• 修改一個component，會影響想到所有使用這個component的testing case
• 解決之道
  • 不要依賴多變的東西
  • 例如GUI常常是多變的，透過GUI來驗證系統就很容易撞到這個問題
  • 在設計系統的時候，商業邏輯應該不要跟GUI耦合
• 小疑問QQ
  • 目前在實作上會寫L2 testing，部分的flow是期待可以測試到頁面的變化。這邊我可不可以理解，說得是除了純粹的頁面驗證之外的情形，還是說純粹的頁面驗證其實也不重要。

THE TESTING API

• 給測試專用的API
  • 目的：
    • 解耦UI測試跟商業邏輯
    • 將測試架構從其他部分的程式邏輯中解耦
  • 超級用戶權限，繞過安全限制
• 小心得
  • 第一次看以為是mock service提供給UI測試的康莊大道
  • 但看完反而對這個存在的目的有點不清楚

STRUCTURAL COUPLING

• 測試code跟被測試code耦合的很緊密，基本上被測試code任何修改都要調整測試code
• 此時也可以透過測試專用API，來解耦這部分，如此就可以在不影響被測試code的前提下，對測試code進行refactor或evolve

SECURITY

• 安全風險很高，要注意不要部署到production，最好可以部署到獨立測試環境

總結

• 測試是系統一部份
• 需要設計如何寫測試，才能達到他的目的
  • 確保系統穩定性
  • 預防潛在問題