自动化测试中，不得不知的替身对象
一个测试替身，是一种可以在一个测试用例中用来代替真实对象的对象，类似于特技替身代替电影中的真实演员。这些测试有时通常被称为“「Mock」（模
要测试 Public APIs，而不是实现细节
public API 可能被任何调用者所使用，而调用者可能会将从任意组合的参数引入到该方法中。 我们当然希望，所有的可能性都能被测试用例覆盖。 这样的话，我们就会
只验证发生状态变化的方法调用
只验证发生状态变化的方法调用 某个对象的方法调用分为两类： 引起状态变化的：有副作用，并且改变了被测代码之外的信息，例如 sendemail()、
保证原因与影响清晰
下面的这个测试写的正确吗？ 208: @Test public void testIncrement_existingKey() { 209: assertEquals(9, tally.get("key1")); 210: } 事实上，如果不知道 tally 这个对象是如何准备的，你就根本不可能确认它是否正确： 1: private final Tally tally = new Tally(); 2: @Before
使用密封服务（Hermetic Servers）进行端到端测试！
想像一下，我们有一个复杂的富Web应用程序。在其之下，可能是由错综复杂的服务器集群提供服务，每个服务器执行不同的任务，而且大多数服务器之间都
使用冒充者(faked)，让测试做得更好！
在写了多年博客之后，你决定尝试一下所用的博客平台的 API 。你开始练习使用它，但你意识到一个问题：你的测试在没有与远程博客服务器进行交互的情况下，
在测试用例中，对服务调用进行契约检查！
下面的测试用例将对 CloudService 的服务调用进行模拟替代（ mocks ）。 这个测试用例真的能为我们提供足够的信心吗，它让你相信：这个服务调用是可以正确工作的了么？ @Test
明明白白地创建测试数据！
**Helper 方法让创建测试数据变得更容易。但随着时间的推移，它们会变得更难理解。**因为您需要测试数据的更多变形，来满足不断变化的新测试要求： // This helper method
像变更检测器一样的测试代码，是有害的！
像变更检测器一样的测试代码，是有害的！ 想像一下，你刚刚完成一次重构（没有改变该应用的外部行为），正打算提交这次变更。但是，为了安全起见，你打