David Ko的學習之旅

TDD 實作經驗分享

Test Driven Development – Personal Experience
http://chaoticjava.com/posts/test-driven-development-personal-experience/

作者分享了他在做TDD的一些經驗:
1. 有個TDD的簡介是非常重要的事情.
開發人員需要知道, 為什麼要改變目前的開發方式, 以及它如何真的節省了開發時間.

如何學習TDD

http://www.slideshare.net/ecr21/intro-coding-dojo-xp2011

很多人都想學習TDD, 可是通常都不知道怎麼開始, 尤其是缺乏實戰經驗的訓練.

在這篇文章中介紹了一些方法.

1. 你可以先開始閱讀一些書籍, blogs, 或是別人的codes

ATDD 相關資料


Textbooks
1. Test Driven - Practical TDD and Acceptable TDD for Java developers
- chapter 9 - 11

Test Fixture

在進行Test driven developemnt時, 常常會提到一個名詞: test fixture. 很多人對這個term不是很了解. 因此我整理了一些資料, 希望有助於大家的了解

1. 定義:
A test fixture is all the things we need to have in place in order to run a test and expect a particular outcome.
A test fixture is a fixed state of a set of objects used as a baseline for running tests.

TDD實作三大策略

Kent 在Test Driven Development by example一書中, 提到了在使用TDD方法來開發程式時, 有三個策略你可以使用:

1. Faking it
- 先用hard code的方式讓程式可以快速通過測試.
- 我們的目標是讓測試快點通過, 先有些進展, 然後再調整和優化程式.

2. Use Obvious Implementation

讀書摘要: 測試是最好的需求敘述

Test Driven Practical TDD and Acceptance TDD for Java Developeres - Lasse Koskela, Chapter 2

很多人認為只要需求寫完整, 或是有寫需求, 自然就可以做出客戶所要的系統.

但是, 事實上, 常常在最後時, 客戶很驚訝地說, 為何你會做成這樣.

五種誤用Fit的行為

Five Ways to Misuse Fit
http://jamesshore.com/Blog/Five-Ways-to-Misuse-Fit.html

Fit (Framework for Integrated Test)是一個非常有名, 用來進行整合測試的framework. 在agile領域中經常被人家來, 進行驗收測試先行(Acceptance Test Drvien Development, ATDD)的工具.

作者根據他的經驗, 發現一般人常會有以下的誤用

1. 拿Fit只來進行測試自動化

TDD實戰道場

TDD Randori session
http://agilepainrelief.com/notesfromatooluser/2008/10/tdd-randori-session.html

這是Mark Levison 在練習TDD的方法, 我想大家可以參考一下, 還蠻有趣的.

他把一群人聚在一起, 利用TDD來解決一個小的問題:
- 利用投影機把電腦的內容打出來, 讓所有餐與者都看得到

不健康的測試行為(Behavior Smells)

1. Assertion Roulette
在一個測試的函式中, 有很多assertion失敗, 你會搞不清楚到底是哪一個有問題, 或是真正的原因是甚麼.

這通常代表這個測試的函式, 一次想要測試很多功能, 所以導致失敗時會顯示多個assertion都不過. 可以適當地, 讓每個測試函式一次測試一個功能, 讓錯誤發生只會有一個 assertion 出現.

當然有時候可能是都沒有適當的 assertion 出現, 所以可能要依靠 debugger 找出問題所在.

2. Erratic Test

測試自動化有關於專案中不好的味道(Project Smells)

在xUnit Test Pattern一書中, 提到測試自動化有三類型的smells: Code Smells, Behaviors Smells 和 Project Smells. 其中 Project Smells 是指從專案角度來看, 有問題的部分.

Project Smells 大致上有以下幾種

1. Buggy Tests
顧名思義, 也就是測試自動化常常發現有問題. 通常這些問題跟 Code Smells 和 Behaviors Smells 有關. 像是 Fragile Test, Obscure Test, 和Hard-to-Test Code 這些都是常見的原因.

在思考要如何解決時, 當然是可以參考 Code Smells 和 Behaviors Smells的解決方法. 但是在Project Smells 中, 需要從專案的角度來著手, 看專案經理能對團隊做些甚麼.

測試自動化的目的 (1)

在 xUnit Test Patterns 一書的第三章中, 提到 Test automation 的 goal. 作者認為應該有以下目的:

1. 應該能幫助我們改進品質
2. 應該能幫助我們了解受測程式
3. 應該能減低風險
4. 應該要能容易執行

測試味道(Test Smell)

Matin Fowler 在 refactoring 一書中, 提到若是你要進行 refactoring 時, 你需要先知道哪裡需要 refactoring. 要如何找出這些地方呢? 這時候你需要知道壞程式的味道(smell)是甚麼, 因此他列出了一堆 smell 讓大家知道.

同樣地, 測試程式也有類似的行為, 也會有匯壞味道. 在 xUnit Test Patterns一書中, 他列出了三種壞味道:

1. Code Smell
- Fowler 認為大部分的 smell 都是 code smell
- Code smell 會影響維護的成本, 並且他也是 behavior smell 的早期徵兆

乾淨的test program會幫助你更有效率

以前花很多時間在維護測試程式, 每次越維護越覺得測試自動化真的是浪費時間, 效果在哪裡也不知道.

最近在看 "xUnit Test Pattern", 我發現很多地方我們似乎做錯了, 所以只是越做越賠錢.

他書中有個簡單的範例, 告訴我們如何 refactor 測試程式, 來達到 test case 可以當作說明文件. 大家可以參考看看, 這樣 refactor 後的結果是否真的幫你很多.

測試程式要很簡單

在寫測試程式時, 常常遇到的問題, 就是維護的代價很高.

原因有很多, 有時候是因為受測程式常常修改, 或者是因為需求有變動, 但有更多時候是因為測試程式自己有 bug, 因為只要是人寫的程式都會有 bug.

再加上我們求好心切, 想把程式寫得更有彈性, 好讓我們能夠更方便測試. 或是想把程式寫的功能更想大, 可以讓我們能測試的狀況更多. 因此我們花在維護程式的花費上, 比我們想像的還多得多. 因此到最後, 我們一聽到要寫測試程式時, 便會退避三舍.

最近看到 the art of unit testing 的一段話, 讓我對測試程式有了新的認識.

TDD無法推行的十大原因

Top Ten Reasons That TDD Sucks
http://www.blueskyonmars.com/2004/03/19/top-ten-reasons-that-tdd-sucks/

1. 沒有足夠時間撰寫測試

2. 測試不是我的工作, 那是QA的工作

3. Unit Test一點都沒有用, 因為我的程式一開始就寫的很完美

選擇性的Unit testing - 從cost和benefit的角度 (2)

Selective Unit Testing – Costs and Benefits
http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/

對程式進行unit test要花費多少cost?

基本上有幾件事情明顯地會有cost:

1. 實際撰寫unit test的時間

選擇性的Unit testing - 從cost和benefit的角度 (1)

Selective Unit Testing – Costs and Benefits
http://blog.stevensanderson.com/2009/11/04/selective-unit-testing-costs-and-benefits/

作者有好幾年的單元測試和TDD經驗, 他發現到unit test在某些事情上, 對於增進品質有很大幫助. 可是在某些項目上, 卻是不容易進行refacotring, 或是在enhancement上要花很大的cost.

他認為unit testing的好處和用處, 大家應該是沒有任何疑問的. 但是對於某些狀況下unit testing很沒有效率, 這件事上大家並沒有共識.

在討論這件事情時, 他先思考unit testing可以帶來什麼好處呢?

stub和mock的比較

Mocking frameworks: stubs vs mocks
http://mindinthewater.blogspot.com/2010/02/mocking-frameworks-stubs-vs-mocks.html

1. Mocks
(1) mock 是藉由提供一連串想要的函式呼叫和對應的傳回值, 來建立所想要測試的流程.
(2) 所以你可以把mock 想像成是戲劇中的演員, 他必須要依據劇本來演出. 劇本內會描述一些預期所要演出的劇情是什麼, 也就是演員必須說出劇本內所描述的句子