過多的設置意味著不佳的模式。你應該只需要設置那些與你正在測試的類直接相關的對象。
盡量讓單元測試精細化，這將帶來可移植性更強的代碼，并將它推向更加清晰、更加獨立的實現。
通過回調制針測試
回調制針（backpointer）完全就是個麻煩事，應該避免其出現。它會帶來相當多的異常，狀態模式就是其中一個。一定要了解自己實現回調指針的理由。如果理由是“它會起作用”，那么你就在失去什么東西。
視圖測試——將測試三要素實例化
在一個構造完好的應用程序里，視圖層應該從域抽象出來，達到一種不需要創建視圖就能夠測試該應用程序的程度。不夠精細的測試需要更加經常地更改。見上文測試打破常規。
這只是來自一個不斷改進的小例子。我再提醒一遍，從簡單的開始，保持其基本框架，得到所有人的同意。
連續集成
瀑布式方法的一個缺陷是代碼庫的集成往往每隔數周或者數月之久才進行一次。新的錯誤常常會隨著代碼的集成而不斷暴露出來，我們不得不花額外的時間來更正錯誤并重新集成。如果集成不是頻繁進行，那么反饋就不可能像應該的那么緊密。敏捷開發要求進行更加頻繁的集成——在3Q的案例里，這意味著每天要集成一到兩次。
大多數小組一般都會有一臺構建計算機，成對的開發人員能夠利用其檢查在測試－編碼－重整循環里編寫好的代碼。每對開發人員都有確信其代碼在被集成到代碼庫之前就已經經過測試和重整。一旦檢驗完畢，自動化的構建計算機就會編譯所有的代碼，運行所有的測試，并通過顯示器（向小組）顯示出來——構建過程是否需要引起注意——例如：新加入的代碼有沒有破壞什么東西？
文章來源于領測軟件測試網 http://www.kjueaiud.com/
