Unit Test相關
經常在軟體開發過程中提到Unit Test
但我發現好像其實很多人不太懂什麼是Unit Test
所以來稍微談一下,不過這網誌主要還是在打我自己的筆記~
但我發現好像其實很多人不太懂什麼是Unit Test
所以來稍微談一下,不過這網誌主要還是在打我自己的筆記~
- Unit Test幾個原則
- FIRST
- Fast
- Isolated
- Repeatable
- Self-Validating
- Timely
- 3A
- Arrange (對應到一般測試框架,大概會叫做Before/Setup)
- Act (TestCase)
- Assert (驗證階段)
- Unit Test的定義
- 首先,這必須是個白箱測試
- 對象是程式中最小的邏輯單元 e.g. function/method
- 對於function的interface(也就是輸入/輸出)做檢查/測試
- Unit Test幾個障礙
- 心理層面---
- Product code 我寫,Test code也我寫?不是應該給QA嗎?!(物件的設計和使用的人都是developer,所以要自己寫)
自己的測試自己寫啊混蛋
- 已經手動測過都對了,還有必要寫 Test code?(未來重構或者新增功能的時候都可以在跑喔-->Repeatable)
- 寫 Test code 好麻煩!(你自己手動測個幾次會更麻煩der)
- 技術層面---
- 要怎麼寫測試?(根據用的程式語言找對應的測試框架來用摟 e.g. Java-->JUnit/Javascript-->Mocha)
- 寫著寫著就變成整合測試了(Integration Test),咦!?(這就是違反了Isolated的原則了,在程式碼中有些相依的物件,所以就需要mock/stub/fake這類的偽物來協助你)
- 到底測了多少勒?(這是個Code Coverage的問題,有些工具會幫你檢查出你所寫的測試到底達到多少覆蓋率)
- 帶來的好處呢?
- 在程式交接時,將測試作為說明書來看,可以快速瞭解每個單元的用途,當然也要記得加上一些註解
- 在新增了新的功能後,將過去的單元測試都跑一次,以確保新增這個功能後,過去的功能沒有壞掉 (這叫做Regression Test 回歸測試)
- 秀下限之最近遇到的困難
最近在測Android的libarary的時候,遇到有相依Android Context的狀況,這樣的情況下單單有libarary是無法測的,查了一下有個叫做Instrumentation Test的方式,準備一個DEMO APP並在與實機連線的狀態下以送ADB指令的方式進行測試,終於是解決了.
不過實際上他傳了什麼指令,到底是怎麼運作還要花些時間搞懂啊~
下篇看看要來E2E Test(就是所謂Acceptance Test) ,還是來記一下mock/stub這些
不過也可能都不是~~
- 心理層面---
- Product code 我寫,Test code也我寫?不是應該給QA嗎?!(物件的設計和使用的人都是developer,所以要自己寫)
自己的測試自己寫啊混蛋
- 已經手動測過都對了,還有必要寫 Test code?(未來重構或者新增功能的時候都可以在跑喔-->Repeatable)
- 寫 Test code 好麻煩!(你自己手動測個幾次會更麻煩der)
- 技術層面---
- 要怎麼寫測試?(根據用的程式語言找對應的測試框架來用摟 e.g. Java-->JUnit/Javascript-->Mocha)
- 寫著寫著就變成整合測試了(Integration Test),咦!?(這就是違反了Isolated的原則了,在程式碼中有些相依的物件,所以就需要mock/stub/fake這類的偽物來協助你)
- 到底測了多少勒?(這是個Code Coverage的問題,有些工具會幫你檢查出你所寫的測試到底達到多少覆蓋率)
- 帶來的好處呢?
- 在程式交接時,將測試作為說明書來看,可以快速瞭解每個單元的用途,當然也要記得加上一些註解
- 在新增了新的功能後,將過去的單元測試都跑一次,以確保新增這個功能後,過去的功能沒有壞掉 (這叫做Regression Test 回歸測試)
- 秀下限之最近遇到的困難
留言
張貼留言