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