你在为你的产品代码编写自动化测试。恭喜你！你还在写代码之前就写了测试？那就更棒了！！仅仅是这么做就可以让你成为一名软件工程实践的先行者。但你写的测试是优秀的吗？如果有一种提问：“我为谁而写测试？”你会怎么回答？若是回答：“为了我，在修复bug上的努力”或者“为了编译器，让它们能够跑起来”，那么你写的测试未必是最好的。所以你到底是为谁而写测试？为了那些想要了解你代码的人们。
好的测试能够充当它们正在测试的代码文档。它们描述了这些代码是如何工作的。对于每种使用场景，这些测试要：
- 描述上下文、切入点，或者必须满足的前置条件
- 说明该软件是如何调用的
- 描述预期结果或者待验证的后置条件
不同版本的使用场景都会所有不同。人们应该可以通过查看少量的测试来尝试理解你的代码，并在上述的测试三部分中进行比对，看到何种情况下会导致该软件的不同行为。每个测试都应该结合上述三条言简意赅地说明因果关系。
这意味着在测试中不可见内容与可见内容一样重要。太多的测试代码把读者的注意力转移到那些不重要的地方。只要有可能，就把这些琐碎隐藏在有意义的方法背后（“提取方法”重构会是你的朋友）。并确保你给出的每个测试都有一个能够描述场景应用的有意义的名字，好让这些测试的读者不必“逆向工程”每个测试才能理解在这种场景下的变化是什么。在此之间，测试类以及测试方法的命名至少应该包括切入点以及软件是如何调用的。可以通过扫一眼方法名就能核实测试的覆盖范围。只要测试方法名对于包含预期结果，只要它的命名不会太长以至于无法查阅，它都会很有用。
测试你的测试用例是一个不错的想法。你可以通过插入一些错误在生产环境的代码，来验证这些测试能否发现你认为应该被发现的错误（当然，你将丢掉你自己的副本）。确保它们在有帮助和有意义的方式下反馈错误。你还应该核实你的测试能够言简意赅的向那些想要理解你代码的人进行讲述。唯一的方式就是叫一个和代码无关的人来阅读你的测试，然后告诉你他从中了解到了什么。仔细听他会说些啥。如果他无法清楚地理解某件事，可能并非他不够聪明。更可能是你做的不够清楚（角色反转一下，去读读他的测试吧！）。
