Fitnesse使用系列一

一、簡介

按標準說法Fitnesse是一個驗收測試框架，先不用理會這些貌似“高大上”的名詞。看看它是如何介紹自己的。在手冊文檔的首頁，定義了四種說明：1.是一個軟件開發合作工具；2.是一個軟件測試工具；3.是一個wiki；4.是一個webserver。

先從最有操作性的特征開始理解：一個webserver，也就是說肯定是以web方式訪問的，就當是個網站好了；一個wiki，這就更具體些了。Wiki是一種百科全書式的站點，通常旨在介紹各種知識。那么fitnesse也類似，可以瀏覽它以獲取我們需要的信息。這些信息當然不是憑空出來的，是我們自己錄進去的，而且往往不是一個人錄進去的。也就是說大家可以各自往里錄入內容，那么當作一個論壇站點也未嘗不可。只是fitnesse安全權限和日志方面比較弱，只能看到最后修改完的內容，哪些部分被修改過、誰修改的、修改了幾次等等，就查不到了，不過這不是它的重點。能夠讓大家共同發信息、共同瀏覽信息，也就達到開發合作的目的了，所以盡管說的抽象，其實很簡單。

到現在為止，定義中的1、3、4都明白了，那么這樣看來和普通的站點并沒有任何不同，而關鍵和有趣的就在于定義2——是一個測試工具。一個站點是如何成為一個測試工具的呢？實際上在fitnesse中有兩種類型的頁面（操作上不止兩種，邏輯上可看作兩種），一種叫做靜態頁面，這就完全是普通的html文字了。另一種叫做執行頁面，特征是上面有個能夠執行的按鈕（有的頁面是test按鈕，有的頁面是suite按鈕，后面會深入介紹），我們可以通過修改一個頁面的屬性，來標明此頁面是普通頁面還是可執行頁面。

二、實現原理

可執行頁面是如何執行的呢？事實上，當我們點擊這個按鈕時，fitnesse自動去啟動一個java命令，java–cp xxxx.jar;xxxx.jar {TEST_SYSTEM} {類名} {方法名}。其中的xxxx.jar是需要我們指定的；{TEST_SYSTEM}需要我們自己定義（默認是兩種，fit和slim，理論上可以自定義擴展，我還沒試，因為現在夠用）；{類名} {方法名}從哪來呢？答案是頁面中的表格，所以表格是fitnesse的一個關鍵因素，下一篇專門講表格。

三、優點

能夠想到把說明性文字和執行操作結合起來，這是我最佩服這個工具初始創意者的地方。根據經驗，項目失敗的很大可能性原因是信息傳導不暢通。在傳統的瀑布開發模式中，需求從用戶傳導到開發人員時，往往會走了樣，這就導致產品接近開發完成時又局部返工甚至全盤返工，項目不失敗才怪了。在敏捷模式中，強調的就是溝通與協作。需求變更要快速、準確的傳達給開發人員。無疑，打電話是最快的，會議討論其次，郵件通知再其次，文檔變更是最慢效果最差的，恰恰又是用的最多的。為什么呢？因為前幾種方式不好留證據、不好歸檔、不好給別人“吹噓”（比如我們的管理多么多么規范，通過了XXX認證，通過了XXX驗收......）。當然前幾種也不是沒有缺點，確實是各有利弊的事，在這不討論這個，單說文檔變更。文檔變更后，即便通知（我這里說的通知不僅指手工發送的郵件，也包括版本管理工具的提醒等）到每個人，恐怕這個效果也是存疑的。因為通知沒有任何約束力，誰看了，看了多少，懂了多少都無法保證。我們也都有這種體會，對于那些枯燥的模板式的文檔，尤其是長篇的，真的很難認真去讀。有時候寧愿打個電話問問怎么回事，也懶得去讀這個。即便讀了，大家的理解是否一致也難說。Fitnesse這種把文檔和操作相結合的方式，就為我們提供了一種可能——在文檔里不光寫明要完成什么，還寫明完成的效果是什么樣的，而且可以執行測試以驗證這個效果。這就是驗收測試（Acceptence Testing）。大家的理解是否正確、一致，由測試的紅綠條決定。綠了就合格，紅的就是有問題（也許需求不合適，也許測試用例不合適，也許代碼有bug，總之看到紅條就提醒大家一起找原因）。在我看來這正是fitnesse的價值所在，而不要把它僅當作自動化測試工具來看待。自動化測試工具或框架有很多，而兼具溝通工具和測試工具的就頗為可貴了。