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

9 lines
1.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

### 11.2.6. 避免的不稳定的测试
如果一个应用程序对于新出现的但有效的输入经常失败说明程序不够稳健;同样如果一个测试仅仅因为声音变化就会导致失败也是不合逻辑的。就像一个不够稳健的程序会挫败它的用户一样,一个脆弱性测试同样会激怒它的维护者。最脆弱的测试代码会在程序没有任何变化的时候产生不同的结果,时好时坏,处理它们会耗费大量的时间但是并不会得到任何好处。
当一个测试函数产生一个复杂的输出如一个很长的字符串或一个精心设计的数据结构或一个文件它可以用于和预设的“golden”结果数据对比用这种简单方式写测试是诱人的。但是随着项目的发展输出的某些部分很可能会发生变化尽管很可能是一个改进的实现导致的。而且不仅仅是输出部分函数复杂复制的输入部分可能也跟着变化了因此测试使用的输入也就不在有效了。
避免脆弱测试代码的方法是只检测你真正关心的属性。保持测试代码的简洁和内部结构的稳定。特别是对断言部分要有所选择。不要检查字符串的全匹配,但是寻找相关的子字符串,因为某些子字符串在项目的发展中是比较稳定不变的。通常编写一个重复杂的输出中提取必要精华信息以用于断言是值得的,虽然这可能会带来很多前期的工作,但是它可以帮助迅速及时修复因为项目演化而导致的不合逻辑的失败测试。