软件开发其实是在修改、演进和维护代码，如果我们不能信任测试，那么在即使看似无辜的改动之后，我们仍然不能确信代码能够工作。
　　注释掉的测试
　　关于测试，有一个特别有趣的注释失效模式是测试方法被注释掉了，它没有传达任何信息，而只是在迷惑人们。我们把注释当做可怜虫的版本控制。将测试的@Test注释掉，也会产生同样的问题。为什么会出现呢？天灾？人祸？临时禁掉事后忘了恢复？谁知道呢。反正不该这样。
　　注释掉的代码，那是死代码。这种代码在当初写的时候曾经具备目的，但是注释掉得代码的价值快速腐坏。
　　歧义注释
　　注释所描述的行为与代码实际行为之间存在差异，这类差异具有误导性。也许这并不致命，但是花费你15分钟去调试这段代码后，发现注释乱写，心情还是不太爽的。这个世界上存在两种注释，好注释和坏注释，显然后者会多一些。遇到这种注释，有两个办法：一是将注释替换为可读性更好的变量和方法，二是从注释中的代码段中抽取一个方法，并妥善命名。其实好的，是“好代码即注释”。
　　永不失败的测试
　　测试该失败时应该失败，永不失败的测试，带给你的只是虚假的安全感。这样的测试多出现于检查抛出异常的测试中，因为很容易被try-catch代码块吞掉。遇到这种情况，需要使用@Expected属性咯。
　　轻率承诺
　　轻易承诺的潜在主题是测试做的比说的少——或根本没做。通常有三类表现：测试无所事事、测试实际上没有测试任何东西，测试名不副实。比如没有断言的测试，或者只有很少的、不重要的断言。解决办法，是要么不做，要么标示出这些测试还未做，比如给出TODO标记，当然，这也是在欠债。
　　降低期望
　　做简单的事情，往往会被理解为敷衍了事，这样做降低了准确性和精度。这种节奏望你走的很快，但是伴随着速度，随之而来的是虚假的安全感。测试对于变化来说过于健壮，以至于测试本该失败时也不会失败。
　　平台偏见
　　软件产品涉及多个平台，测试也是这样。测试无法平等的应对所有平台，即所谓的平台偏见。对于跨平台，或者不同的测试环境，需要对外暴露，不能隐藏平台差异的信息。而对于实际执行时，可以选择mock等方式屏蔽掉平台不同的细节，以使测试能够执行。关于平台，有换行和回车符（WIndows是 ，Unix是 ），千万不要硬编码。
　　平台偏见是有条件的测试的特例：执行或不执行一个隐藏在测试中的基于条件的测试。
　　有条件的测试
　　有条件的测试是在一个测试方法中隐藏了秘密条件，使测试逻辑名不符实。遇到这种测试，要确保每个条件分支都在适当的时候触发失败。
　　总之，当某些被破坏时，测试什么也不告诉你，那是不可靠的坏味道。