谷歌的测试工程师是如何工作，帮助开发工程师提升生产效率的
现在，越来越多的软件系统采用了「微服务架构」。尽管这种架构对于多人参与的大系统，为多个功能特性的并行开发与无停机部署提供了便利，但对整个系统
仅验证与其被测行为相关的方法参数!
每个测试只应该验证一个行为，这可以使测试用例更可读，更能适应变化。 下面这段测试代码为 MockUserPrompter 的所有参数指定了精确值。一旦被测试的代码发生更改，这些
测试用例太 DRY 了? 应该让它们 DAMP!
下面的测试用例遵循了 DRY 原则 (“Don’t Repeat Yourself”), 它是鼓励重用，消除重复的一个最佳实践，例如, 通过抽取 helper 函数 或 通过使用循环的方
要测试行为（Behaviors），不要测试方法(Methods）
在编写一个method()之后，只需编写一个测试，就可以轻松地验证方法的所有功能。但是认为测试与public method方法应该是一对一的关
自动化测试中，不得不知的替身对象
自动化测试中，我们常会使用一些经过简化的，行为与表现类似于生产环境下的对象的替身。引入这样的替身对象能够降低构建测试用例的复杂度，允许我们独
要测试 Public APIs，而不是实现细节
公有的 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应用程序。在其之下，可能是由错综复杂的服务器集群提供服务，每个服务器执行不同的任务，而且大多数服务器之间都