单元测试的可信赖性

单元测试的可信赖性

软件开发其实就是在修改、演进和维护代码，如果我们不能信任测试，那么在即使看似无辜的改动之后，我们仍然不能确信代码能够工作。

注释掉的测试

注释掉的代码，那是死代码。这种代码在当初写的时候曾经具备目的，但是注释掉得代码的价值快速腐坏。

歧义注释

注释所描述的行为与代码实际行为之间存在差异，这类差异具有误导性。也许这并不致命，但是花费你15分钟去调试这段代码后，发现注释乱写，心情还是不太爽的。这个世界上存在两种注释，好注释和坏注释，显然后者会多一些。遇到这种注释，有两个办法：一是将注释替换为可读性更好的变量和方法，二是从注释中的代码段中抽取一个方法，并妥善命名。其实最好的，是“好代码即注释”。

永不失败的测试

测试该失败时就应该失败，永不失败的测试，带给你的只是虚假的安全感。这样的测试多出现于检查抛出异常的测试中，因为很容易被try-catch代码块吞掉。遇到这种情况，需要使用@Expected属性咯。

轻率承诺

轻易承诺的潜在主题是测试做的比说的少——或根本没做。通常有三类表现：测试无所事事、测试实际上没有测试任何东西，测试名不副实。比如没有断言的测试，或者只有很少的、不重要的断言。解决办法，就是要么不做，要么标示出这些测试还未做，比如给出TODO标记，当然，这也是在欠债。

降低期望

做最简单的事情，往往会被理解为敷衍了事，这样做降低了准确性和精度。这种节奏望你走的很快，但是伴随着速度，随之而来的是虚假的安全感。测试对于变化来说过于健壮，以至于测试本该失败时也不会失败。

平台偏见

软件产品涉及多个平台，测试也是这样。测试无法平等的应对所有平台，即所谓的平台偏见。对于跨平台，或者不同的测试环境，需要对外暴露，不能隐藏平台差异的信息。而对于实际执行时，可以选择mock等方式屏蔽掉平台不同的细节，以使测试能够执行。关于平台，有换行和回车符(WIndows是\r\n，Unix是\n)，千万不要硬编码。

平台偏见是有条件的测试的特例：执行或不执行一个隐藏在测试中的基于条件的测试。

有条件的测试

有条件的测试是在一个测试方法中隐藏了秘密条件，使测试逻辑名不符实。遇到这种测试，要确保每个条件分支都在适当的时候触发失败。

总之，当某些被破坏时，测试什么也不告诉你，那就是不可靠的坏味道。