回到简体

ch11/ch11-02-6.md

@@ -1,8 +1,8 @@
-### 11.2.6. 避免的不穩定的測試
+### 11.2.6. 避免的不稳定的测试
 
-如果一個應用程序對於新出現的但有效的輸入經常失敗説明程序不夠穩健；同樣如果一個測試僅僅因爲聲音變化就會導致失敗也是不合邏輯的。就像一個不夠穩健的程序會挫敗它的用戶一樣，一個脆弱性測試同樣會激怒它的維護者。最脆弱的測試代碼會在程序沒有任何變化的時候産生不同的結果，時好時壞，處理它們會耗費大量的時間但是併不會得到任何好處。
+如果一个应用程序对于新出现的但有效的输入经常失败说明程序不够稳健；同样如果一个测试仅仅因为声音变化就会导致失败也是不合逻辑的。就像一个不够稳健的程序会挫败它的用户一样，一个脆弱性测试同样会激怒它的维护者。最脆弱的测试代码会在程序没有任何变化的时候产生不同的结果，时好时坏，处理它们会耗费大量的时间但是并不会得到任何好处。
 
-當一個測試函數産生一個複雜的輸出如一個很長的字符串，或一個精心設計的數據結構或一個文件，它可以用於和預設的“golden”結果數據對比，用這種簡單方式寫測試是誘人的。但是隨着項目的發展，輸出的某些部分很可能會發生變化，盡管很可能是一個改進的實現導致的。而且不僅僅是輸出部分，函數複雜複製的輸入部分可能也跟着變化了，因此測試使用的輸入也就不在有效了。
+当一个测试函数产生一个复杂的输出如一个很长的字符串，或一个精心设计的数据结构或一个文件，它可以用于和预设的“golden”结果数据对比，用这种简单方式写测试是诱人的。但是随着项目的发展，输出的某些部分很可能会发生变化，尽管很可能是一个改进的实现导致的。而且不仅仅是输出部分，函数复杂复制的输入部分可能也跟着变化了，因此测试使用的输入也就不在有效了。
 
-避免脆弱測試代碼的方法是隻檢測你眞正關心的屬性。保持測試代碼的簡潔和內部結構的穩定。特别是對斷言部分要有所選擇。不要檢査字符串的全匹配，但是尋找相關的子字符串，因爲某些子字符串在項目的發展中是比較穩定不變的。通常編寫一個重複雜的輸出中提取必要精華信息以用於斷言是值得的，雖然這可能會帶來很多前期的工作，但是它可以幫助迅速及時脩複因爲項目演化而導致的不合邏輯的失敗測試。
+避免脆弱测试代码的方法是只检测你真正关心的属性。保持测试代码的简洁和内部结构的稳定。特别是对断言部分要有所选择。不要检查字符串的全匹配，但是寻找相关的子字符串，因为某些子字符串在项目的发展中是比较稳定不变的。通常编写一个重复杂的输出中提取必要精华信息以用于断言是值得的，虽然这可能会带来很多前期的工作，但是它可以帮助迅速及时修复因为项目演化而导致的不合逻辑的失败测试。