本节书摘来自华章出版社《有效的单元测试》一书中的第2章，第2.3节，作者 （芬）Lasse Koskela，更多章节内容可以访问云栖社区“华章计算机”公众号查看
在阅读和调试代码以找出不良系统行为的原因时，我却最终不止一次地回到了开始的地方。在找bug的过程中，尤其容易忽略的一个烦人细节是测试的内容。在挖掘代码时，我要做的头一件事情往往是运行所有测试，让它告诉我哪些正常，哪些不正常。有时我太过相信测试的名称。有时那些测试其实完全是在测试不同的东西。这与良好的结构有关——如果测试的名字错误地表达了要测试的内容，那就像是跟着错误的路标驾驶。你应该能够信任你的测试。几年前我为某个产品审计代码，该代码开发了已经超过十年。那是个巨大的代码库，我从结构中可以分辨出某些部分明显比其他部分要新。区分新旧代码的一个线索是自动化测试的存在。但我很快发现，我无法从测试的名字来分辨出要验证的内容，再仔细看，发现测试根本没有在验证它承诺的内容。它不是Java代码，但我把它翻译成了Java的例子：
看到这段代码你立刻能注意到测试的命名不够理想。但再仔细看看，无论“mask”对于“Bmap”意味着什么，测试也仅仅是检查了某些参数是否为有效的组合。如果输入正确的情况下实际行为却仍然有误，那么参数能否通过验证也就变得无关紧要了。关于测试正确的事物这件事其实有很多话要说，但用正确的方式测试正确的事物也很关键。从可维护性角度尤其重要的是，你的测试应该检查预期行为而非具体实现。下一章会涉及这个话题，现在先按下不表。
相关资源：敏捷开发V1.0.pptx