QuEyeCIA 測試之路

前情提要

QuEyeCIA 簡單架構圖

一開始有測試，但是後來卻沒有繼續寫 ?

• 覺得測試沒有必要

  • DataAccess 的部分不必要，因為無商業邏輯，只是單純去資料庫拿資料

    • 
    • 
    • 

  • 測試沒有 Assert

    • 

• 忙著開發，沒空補測試

• 測試案例不好寫，現有的架構有大量的注入

  • 

為何要重新開始寫測試 ?

• 常常改壞東西
• 沒有測試難以重構
• 修復 BUG 時間多

程式這麼多，測試從哪裡開始寫

寫測試的時機

• 新的程式

• 即將要修改的程式，是補上測試的好時機

• 把客戶的案例當作測試案例

  • 

常壞的程式、風險高的補上測試

• 通常 20% 的程式碼會有 90% 的 BUG，所以會針對 20% 的程式去寫
• 針對系統的核心，補上測試
• 最常變動或改動的程式，補上測試

重構的程式補上測試

• 重構之前將測試寫好，在重構時會幫上很多的忙
• 寫一個 失敗 的測試，重構完成後確保此測試是可以運作
  • 以 QuEyeCIA 為例，我們會建立一個不該被建立起來的關聯當失敗案例，確保後續重構後這條關聯也不會被建立起來

被大量使用的程式碼

• Utils : 此類依賴數很少，但是包含大量的邏輯。容易測試，且有價值
  • 之前有過 Utils 改壞，導致系統很多地方都壞掉

    • 

    • 

設定具體目標 (以 QuEyeCIA 為例)

• Code review 時先檢查測試

  • 檢查是否有新增測試
    • 
  • 檢查測試方法的名稱是否呈顯具體的內容，Assert 是不是符合預期的
    • 

• 是否降低修復 Bug 的時間

  • (沒有測試時) 改完 Bug 需要啟動 Server 跑專案，來確認 Bug 是否還存在 (花費大概 10分鐘)
  • (有測試時) 改完 Bug 只需點一個按鈕，就知道 Bug 是否還存在 (花費大概 1~2 秒)

• 測試涵蓋度是否提升 (可選)

  • 測試涵蓋率高一定好嗎 ?
    • 不一定，但是可以當一個指標看看就好
    • 因為可以寫一堆無用的測試去堆高測試涵蓋率
    • 建議是指針對核心去做測試，得到的效益比較好
  • 整體測試涵蓋

    • (之前)

    • (之後)

  • 核心測試涵蓋
    • 

加入測試到底會增加開發時間還是縮短開發時間 ?

• 我們會在 Plan Metting 時把測試的時間加入開發時間，所以一開始的開發時間一定比較長

  • 

• 測試雖然會增加開發時間，但是後續的可維護性，跟容易修復 Bug 的時間反而可以縮短專案的開發時間，客戶發現的 Bug 也比較少。(以單元測試的藝術統計為例)

  • 

  • 

• 結論是可以縮短整體開發的時間，且 Bug 較少

自動化測試 (以 QuEyeCIA 為例)

• Jenkins daily build
  • 當有問題出現時

    • 

    • 

    • 

對 CIA 來說寫測試的優點

• 比較不怕改壞東西
• 知道程式支援哪些情境，沒寫測試的列為不支援
• 有測試時，重構有一定的信心不會重構到壞掉

未來展望

• 希望將一些還沒補上測試的核心程式補完
• 持續提升程式的可測試性，並減少相依性