測試：開發人員理想與現實的大PK

PDC大會上進行了關於“單元測試的未來”的小組討論，大部分的談話內容聚焦於Mock測試，人們對於Mock 框架（Mock frameworks）的過度使用取得了普遍共識。

共識如下：通常，實現所有必要的介面非常無聊，而且消耗時間。為了更方便，人們選擇了Mock 框架。但這遮蓋了更本質的問題：API被設計得過於複雜。

關於“開發人員測試”與其他人員的測試之間的區別，有一個熱門的話題。一直以來的討論中，人們都認為開發人員只需要做單元測試，而需求測試、驗收測試、整合測試，以及所有其他形式的測試都是其他人的工作。

這裡強調了在單元測試社群中存在的一個普遍誤解。具體來說，就是假設所有開發人員都配備了QA團隊，以處理所有其他型別的測試。不幸的是，即使是擁有數百萬資金的公司也往往根本沒有QA資源，所有的測試都留給了開發人員和終端使用者。

開發人員無法進行更多型別測試的主要原因是速度。 單元測試已經太慢了，因此沒有更多時間去進行那些更慢的測試了，比如包括網路通訊的測試。 遺憾的是，並沒有人考慮其他變通之策。

舉個例子，單元測試框架其實可以更加智慧，它們可以使用程式碼覆蓋率的結果，只對發生變化的程式碼進行二次測試。一個類的變化，不應該觸發重新執行所有的測試集合。所謂“單元測試”意味著你只需測試一個小的子集即可。

另外一種沒有被提及的改進是利用分散式程式設計。程式碼和測試可以被快速上傳到各個伺服器並且得到執行。通過引入持續整合，我們已經擁有了所有需要的技術。

早些的討論普遍覺得資料庫方面被忽視了，大部分的資料庫開發人員很少或幾乎沒有單元測試的概念，也缺乏相關支援工具。更可怕的是，他們甚至都沒有被邀請來參加討論。遺憾的是這就是目前的現狀。討論中也沒有提供方法改善這些現實問題。

從好的方面看，已經有一些人在討論使用建模工具來讓單元測試更加簡單。他們提供了很多可選的辦法，例如從定義契約級別開始。這些契約可以被程式碼生成器用來編寫實際的測試程式碼。顯然，這並非一個100%完美的解決方案，但它能夠減少經常遇到的困難。

另一個被看好的辦法是採用delta狀態管理。設想測試“取錢”這個功能，很多人會假設被測試帳戶最開始有100美元，經過交易後，剩下80美元。這個方法就是首先查詢一下賬號餘額，然後再看是否減少了20美元。這樣一來，就不必在每次執行測試時都重新設定測試環境了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-566786/，如需轉載，請註明出處，否則將追究法律責任。