TotT

单元测试一定要聚焦

写测试时,应该是每个场景都应该在独自的测试用例中进行验证,它的好处在于: 逻辑更容易理解,因为在每个测试方法中需要理解的代码更少。 每个测试中的

继续阅读

要测试行为(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应用程序。在其之下,可能是由错综复杂的服务器集群提供服务,每个服务器执行不同的任务,而且大多数服务器之间都

继续阅读

使用冒充者(faked),让测试做得更好!

在写了多年博客之后,你决定尝试一下所用的博客平台的 API 。你开始练习使用它,但你意识到一个问题:你的测试在没有与远程博客服务器进行交互的情况下,

继续阅读

在测试用例中对服务调用进行契约检查!

下面的测试用例将对 CloudService 的服务调用进行模拟替代( mocks )。 这个测试用例真的能为我们提供足够的信心吗,它让你相信:这个服务调用是可以正确工作的了么? @Test

继续阅读

不要把逻辑放在测试用例中!

**编程语言给了我们很大的表达能力。**运算符和条件表达式等概念是重要的工具,让我们能够编写程序,处理各种各样的输入。但是,这种灵活性是以增

继续阅读