不论我们是在写一个单独的单元测试，还是设计一个产品的完整测试流程，退后一步想一想我们的测试在发现代码Bug方面的效率如何都是很有意义的。为了更高效，有3个重要的质量，需要每个测试用例都尽力做到最大化。
Fidelity(可信度)
当待测代码被破坏了，测试用例应该break。
一个高Fidelity的测试用例对于待测代码的缺陷极其敏感的，防止bug偷偷潜入我们的代码中。
通过保证测试用例覆盖了所有通过你代码的路径并包含所有相关的断言，来最大化Fidelity。
Resilience(韧性)
一个测试用例在待测代码没有引入缺陷时，不应该break。
一个具备韧性的测试用例，当且仅当待测代码引入了破坏性修改时，才会失败.
对于代码的重构以及其他的非破坏性修改不应该需要修改测试用例，以降低测试用例的维护成本。
通过测试待测代码明确暴露的接口，以最大化韧性；避免深入到代码的内部实现细节。使用stubs及fakes，而不是mocks；不要验证与相关依赖的交互，除非这交互是你明确要验证的关键部分。一个脆弱的测试用例显然韧性是非常低的。
Precision(精准)
当一个测试用例失败时，一个精准的测试用例会准确的告诉你是哪里引入了缺陷。一个好的单元测试可以准确的告诉你哪一行代码是有问题的。质量较低的测试用例(尤其是大型end-to-end测试)通常是精准度极低的，只告诉你有东西挂了，但没说哪里挂了。
通过保持你的测试尽可能的规模小且专注，可以最大化精准度。选择一个描述性的方法名字，改名字应该充分且准确的表达这个测试用例在验证些什么。对于系统集成测试，在每个边界处验证状态。
综述
上述的3个维度通常是互斥的。写一个高韧性的测试用例是很简单的(比如说一个空的测试用例)，但写一个同时具备较高可信度和较高韧性的测试用例是非常困难的。
在你做设计或是写测试用例时，可以使用上述三个维度作为引导实现的框架
文章翻译自
https://testing.googleblog.com/2014/05/testing-on-toilet-effective-testing.html