單元測試, Unit Test
TDD, Test Driven Develop
BDD, Behavior Driven Develop
簡介
Adison Wu
adison.wu@gmail.com
內容大綱
❖ 前言
❖ 說明、介紹、實作單元測試 Unit Test
❖ 用法介紹
❖ 覆蓋率介紹
❖ 與其他相關技術的關係
❖ 與其他常提及技術、開發流程的關係
Unit Test
❖ Unit: 最小單元,在程式中為方法 method
❖ Unit Test: 對方法進行測試
❖ 優點: 族繁不及備載..所以看別人整理的比較快
範例環境
❖ 環境
eclipse luna (內建 junit 3, 4)
安裝套件:
EclEmma Java Code Coverage (覆蓋率用)
❖ 範例: 羅馬數字轉換器範例
https://bitbucket.org/adison/unit-test-demo
無測試作法
❖ 範例: No-Auto-Test 分支
❖ 作法
❖ 寫完程式,然後手動測試..
❖ 改完程式,然後手動測試..
❖ 問題
❖ 程式有多少可能?
❖ 每改一次都要跑一次?
❖ 我們知道引用了什麼物件,但怎麼知道被引用物件以及改變後的影響範圍
?
Unit Test 基本用法
Hello World:
Step 1
範例: Unit-Test 分支
寫完物件後,建立一個新的 Junit Test
Case
Unit Test 基本用法
Hello World:
Step 2
測試物件名稱,慣例上會用 test 開頭
小寫表示與正規物件不同
test 開頭表示是測試用物件
Unit Test 基本用法
Hello World:
Step 3
預設內容
Unit Test 建議從一個不會通過的測試開始
,然後直接測試,確認這功能確實尚未實
作
Unit Test 基本用法
Hello World:
Step 4
執行測試
Eclipse 上,在不同區域執行的範疇會不同
(在專案、在物件、在方法)
這種作法只會執行該方法
Unit Test 基本用法
Hello World:
Step 5
Junit Tab 上會出現測試結果
位置可能根據 layout 有所不同
Unit Test 基本用法
Hello World:
Step 6
放兩個可以過的測試
AssertEquals: 判斷內容是否相等
Unit Test 基本用法
Hello World:
Step 7
再跑一次
Unit Test 基本用法
Hello World:
Step 8
通過測試了!這是一個奇蹟!!
Unit Test 基本用法
Hello World:
Step 9
萬一失敗,會提示錯誤地點
剛剛發生了什麼事?
❖ 展示 Unit Test 過程
❖ 新增了測試案例
❖ 用測試語法(AssertEquals) 輸入了測試條件
❖ 執行自動測試流程,判斷是否有測試失敗
Unit Test還有哪些可能?
❖ Junit Org官網網址
❖ 更多斷言方法: AssertThat, AssertNotEquals, AssertNull,
AssertNouNull….
❖ 前置後置處理, Before and After: 針對不同測試進行的前置/
後置處理
❖ Mock and Stub: 針對複雜環境,可透過提供偽資料/物件或攔
截方法取得測試結果
❖ 延伸作法: 覆蓋率檢查, Integration Test, CI
前置後置處理
Before/After Test
BeforeClass, AfterClass: 測試物件開始前/結
束後呼叫 (static)
Before, After: (物件內)每個測試方法執行前/
執行後呼叫
Junit4 使用 annotation 方式, ex @Before
Junit3 使用特定方法名稱 setUp/tearDown,
setUp/tearDownClass
Mock, Stub 簡介
Mock, Stub
Mock:
形似的個體
Stub:
覆蓋率
❖ 覆蓋率: 測試案例涵蓋的內容
❖ 計算方式: 行數、方法數、可執行路徑
❖ 可執行路徑:if/else, while, switch
❖ EclEmma Java Coverage: 覆蓋率套件
❖ 中文介紹
EclEmma Java Coverage
基本用法
在方法、物件或專案上,右鍵選擇
Coverage As
EclEmma Java Coverage
結果畫面
切換到 Coverage tab
綠色代表有測試到
EclEmma Java Coverage
取消對 x4 的測試
黃色: 未執行到內容的判斷
紅色: 從未執行的內容
哪些內容該被覆蓋/測試?
❖ 邏輯元件
❖ 控制元件
❖ 與 UI 無關
❖ 義大利麵程式(UI+邏輯煮成的程式大餐)怎麼辦?多加點辣椒,大口
吞下去
❖ 有些事你永遠不必問,有些人你永遠不必等
❖ 重構吧..
❖ 這都不要?那這招總行了吧
剛說的重構是啥?
❖ 推薦書籍: 重構 — 改善既有程式的設計
❖ Refactor 的重點是在不改變程式外在行為的情況下改進程
式內部的架構
可是教練,我就是想要寫測試
❖ 自動化測試方法其實很多..
http://openhome.cc/Gossip/JUni
t/
❖ 能力越大,責任越大
❖ 程式越複雜,測試越難寫
❖ 方法內部的流程越複雜,測試越
難完善
單元測試結尾感言
❖ Unit Test 是一個提供驗證程式結果是否與預期符合的自
動化方式
❖ 優點:
❖ 自動化
❖ 自我驗證
所以,那個TDD呢..
❖ 先看範例: TDD 分支
❖ 精神
❖ 先決定結果的測試方式,再寫程式
❖ 執行測試看結果
❖ 測試即文件
❖ 與敏捷開發/BDD/IT/CI的關係
TDD? BDD? 能吃嗎?
❖ 不行,不過 BUG 可以
❖ TDD, Test-Driven Development, 測試驅動開發
寫方法/物件前先寫測試, 測試案例就是程式規格
❖ BDD, Behavior-Driven Development, 行為驅動開發
ATDD: Acceptance Test Driven Development 驗收測試
驅動開發
Specification by Example, 規格範例
基於驗收方法/條件、規格說明、USer Story等寫測試
傳統瀑布流 V 型流程
❖ V 型流程
W 開發模型
❖ 每一步驟都有對應的測試方法
W模型的起源
❖ 傳統開發
❖ 瀑布流
❖ 一次性開發,前期花很多時間進行分析
❖ 敏捷開發
❖ 多次迭代
❖ 一次做一點,像雕塑一樣,一次做一部分,系統是不停
演進、不斷變更
所以 TDD/BDD 是?
❖ Unit Test: 單元測試,測試方法
❖ TDD: 測試先行的開發方法, 規格決定後,先寫好(部分)測試再開
發(對應)程式方法
❖ BDD/ATDD: 做好對應設計後,也一併決定測試方式的設計方法
❖ 優點: 通過測試案例的程式一定可以通過測試(啥?
❖ 測試案例來自規格,通過了測試案例 = 達到及格標準
❖ 嫌60分太低?那100分的標準在哪?
BDD, 行為驅動開發範例
❖ 建立使用者行為的測試結果
❖ When, Given, What
❖ 搞笑談軟工 BDD(2)
❖ 搞笑談軟工 BDD(3)
❖ 搞笑談軟工 BDD(4)
環境建置
❖ convert to Maven project
❖ if faile: add m2e connector, window > preference >
Maven > Discovery > open category > find all M2E
connector by Jboss
❖ add cucumber settings to maven’s dependency
❖ info.cukes/cucumber-java/1.2.2
❖ info.cukes/cucumber-junit/1.2.2
❖ junit/junit/4.12
BDD 套件 - Natural
❖ Natural: 官方 wiki
❖ Cheng-Wei Chien 的簡單說明
❖ 安裝
❖ eclipse 新增站台 http://rlogiacco.github.com/Natural
❖ xText 2.6+
Hello BDD
❖ follow BDD3 webpage
❖ BUT!! use @CucumerOption instead of
@Cucumber.Options, which is deprecated
❖ .feature: 功能說明文件
❖ GreetingTest.java: 測試案例(測試 Greeting)
❖ HelloClass, HelloStepDef: 膠水程式,黏合文件與實際測試
❖ Hello.java: 實際物件
TDD/BDD/ATDD?
❖ W型流程中的產出結果
❖ 由設計人員決定的測試方法
❖ 適用於需求不斷變更的專案
❖ 實際順序 ATDD&BDD > TDD > Unit Test > Refactoring
Something in mind
❖ There is not silver bullet, neither TDD/BDD/ATDD.
❖ 自從我吃了TDD,考試都拿一百分了呢(神棍調
❖ TDD is DEAD!! Long life testing.
❖ 懶人包:TDD is Dead 戰文總整理
推薦閱讀
❖ 開源框架:JUnit Gossip
❖ 30天快速上手 TDD
❖ 搞笑談軟工
❖ 自從我吃了TDD,考試都拿一百分了呢(神棍調
❖ TDD is DEAD!! Long life testing.
❖ 懶人包:TDD is Dead 戰文總整理

單元測試介紹

Editor's Notes

  • #3 單元測試一點都不難,就像被蚊子叮一樣,學一下很快就懂了 TDD, 測試驅動開發 test-driven development BDD, 行為驅動 behavior-driven development ATDD, 驗收測試驅動開發 Acceptance test-driven development
  • #4  https://bitbucket.org/adison/unit-test-demo-roman-digit-converter https://bitbucket.org/adison/tdd-demo-roman-digit-converter
  • #9 證明測試案例有效 如果通過了..不是測試方法撰寫錯誤,就是這功能已經存在現存系統中。 無論哪個都是很有意義的結果
  • #17 還有更多的測試方法、測試準備 以及因應複雜資料、遠端物件、第三方物件的作法
  • #26 因此很多設計模式的起源與效果都與讓測試更簡單有關
  • #27 自動化代表只要按一下就好,不用每次都重新追蹤一次 而且是一種可以出報表的結果, 也因此是 持續整合的基礎技術
  • #28 為何而來
  • #29 BDD http://teddy-chen-tw.blogspot.tw/2014/09/bddtdd.html
  • #31 需求測試的產出是 user story 文件 架構測試比較像是傳統規格書,但多了測試條件 元件測試、單元測試的產出就是TDD 缺點:一次只做一點,無法做全局最佳化 有一天會亂掉,因此需要一些額外的成本(重構) 時程難估 優點: 不容易做出不符合需求的東西 特色每次的產出都是可運作的系統,所以1. 隨時有可運作的程式 2. 每次都需要完整測試
  • #33 TDD 不保證全局最佳化 每次都在前一系統的屍體上進化,會有一定程度的重構
  • #34 http://teddy-chen-tw.blogspot.tw/2013/07/bdd4cucumber-jvm.html
  • #35 group id/ article id/ version
  • #36 支援 Cucumer, JBehave
  • #39 TDD 作法並不適合所有環境,也不該套用於所有情況