测试用例太 DRY 了? 应该让它们 DAMP!
下面的测试用例遵循了 DRY 原则 (“Don’t Repeat Yourself”), 它是鼓励重用，消除重复的一个最佳实践，例如, 通过抽取 helper 函数 或 通过使用循环的方
要测试行为（Behaviors），不要测试方法(Methods）
在编写一个method()之后，只需编写一个测试，就可以轻松地验证方法的所有功能。但是如果你认为，测试用例与 公开方法（public metho
自动化测试中，不得不知的替身对象
一个测试替身，是一种可以在一个测试用例中用来代替真实对象的对象，类似于特技替身代替电影中的真实演员。这些测试有时通常被称为“「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