gopl-zh.github.com/ch11/ch11-02-6.md

11.2.6. 避免的不穩定的測試

如果一個應用程序對於新出現的但有效的輸入經常失敗説明程序不夠穩健；同樣如果一個測試僅僅因爲聲音變化就會導致失敗也是不合邏輯的。就像一個不夠穩健的程序會挫敗它的用戶一樣，一個脆弱性測試同樣會激怒它的維護者。最脆弱的測試代碼會在程序沒有任何變化的時候産生不同的結果，時好時壞，處理它們會耗費大量的時間但是併不會得到任何好處。

當一個測試函數産生一個複雜的輸出如一個很長的字符串，或一個精心設計的數據結構或一個文件，它可以用於和預設的“golden”結果數據對比，用這種簡單方式寫測試是誘人的。但是隨着項目的發展，輸出的某些部分很可能會發生變化，盡管很可能是一個改進的實現導致的。而且不僅僅是輸出部分，函數複雜複製的輸入部分可能也跟着變化了，因此測試使用的輸入也就不在有效了。

避免脆弱測試代碼的方法是隻檢測你眞正關心的屬性。保持測試代碼的簡潔和內部結構的穩定。特别是對斷言部分要有所選擇。不要檢査字符串的全匹配，但是尋找相關的子字符串，因爲某些子字符串在項目的發展中是比較穩定不變的。通常編寫一個重複雜的輸出中提取必要精華信息以用於斷言是值得的，雖然這可能會帶來很多前期的工作，但是它可以幫助迅速及時脩複因爲項目演化而導致的不合邏輯的失敗測試。