Fitnesse for designer

對於design，當前我們存在這樣的問題：test code夠不完善，有bug不好發現，發現了不好定位，改完了可能引發其他問題而test code能夠跑過。 這個想想以前定義的關於“root cause”和“code coverage improvement”的story應該可以瞭解。

Fitnesse用於regression testing, daily-build integration functional testing 會在一定程度保證quality的基礎上提高team的效率。對於design, 寫test有時比較無奈：進度壓力，quality要求。 這裏“進度壓力”不是解釋一切問題的套話。

對於design， 我們寫UT、FT最終是爲什麼？是不是所有的source code都要用UT覆蓋？這個問題不做討論。下面的內容的前提是：source code會被覆蓋，但不一定都是UT；quality會在一定程度上保障，但不一定是追求的code coverage。

我們目前使用的Fitnesse，test時會run我們對外功能接口，與我們目前在test中寫的很多測試方式類似。大膽的設想一下，我們把當前test裏的某些test由Fitnesse代勞會怎麼樣？大家肯定會有很多擔心，注意我們這樣做需要幾個前提重要的條件：
1. code要簡單易測試， 將業務邏輯code與common code區分開，定義合理的對外接口，這個接口不等同於我們目前在code中定義的抽象的interface，我們可以從TDD的角度理解爲是爲了run過測試寫的接口；
2. 對code寫“必要”的UT，構造合理的輸入參數，測試各種邊界條件；
3. design與test保持溝通，Fitnesse的case要保障。

當然，做到以上幾點，即便不借助Fitnesse，quality也能保障，但做兩次functional test需要考慮。從以往的經驗來看，design與test的協同工作，出現issue的數量會小的多，其中原因大家很清楚。從當前行業狀況來看，出於響應變化的考慮，嚴格的分階段分過程的做法是值得商榷的，等待一切都OK再開始的做法很難操作。有點跑題了，回到design上，quality不是隻體現在數據上，追求數據可能會讓數據沒有太多有效價值，非左即右的做法不可行，如何更好，我們一直在探索與實踐。