JUnit in Action 2nd Edition 第三章 精通Junit（1）

第三章 精通JUnit

到目前为止，我们做了JUnit综述和演示如何使用（第一章）。我们也看到了JUnit内部的核心类和方法，它们如何同其它的交互（第二章）。

我们现在通过介绍实实在在的组件和测试来深度挖掘它，在这一章中，我们使用控制器设计模式实现一个小的应用，我们然后使用JUnit测试这个应用的每一个部分，当编写和组织测试时我们也将看到JUnit的最佳实践。

3.1 介绍控制器组件

《Core Java EE Patterns》中描述控制器controller作为一个组件，“同客户端交互，控制

和管理每一个请求的处理”。然后告诉我们它用于表示层和业务层模式。

通常，一个控制器有如下行为：

n 接受请求

n 在请求上执行公共的计算

n 选择一个合适的请求处理程序

n 路由请求，因此处理程序能够执行相关的业务逻辑

n 可以为错误和异常提供一个顶层的处理程序

你会发现在各种各样的应用中控制器普遍地使用。例如，在一个表示层模式，一个web控制器接受HTTP请求和提取HTTP参数，cookies，HTTP头文件，可能使用HTTP元素容易地访问应用程序的其余部分。一个web控制器基于请求元素决定调用合适的业务逻辑组件。也许在HTTP会话持久性数据的帮助下。数据库，或者一些其他资源。Apache Struts框架就是一个web控制器的例子。

控制器另一常见的运用是在业务层模式中处理应用程序。许多业务应用支持多个表示层，HTTP客户端可以处理web应用。Swing客户端可以处理desktop应用，在这些表示层下，常常有一个应用控制器或者状态机。程序员实现许多Enterprise JavaBean（EJB）应用以此方式，EJB层有自己的控制器，通过一个业务外观模式或者委派模式连接不同的表示层。

它给出了控制器的多种用途，就不会惊讶于控制器出现在大量的企业架构模式中，包括Page Controller，Front controller,Application Controller。

控制器的设计是你实现这些经典模式的第一步，让我们完成一个简单控制器的代码。看如何工作，然后尝试一些测试。如果你想跟着自己的感觉与运行测试。本章所有的源代码都在SourceForge中可以找到（http://junitbook.sf.net）。附录A中有关于这些源代码设置信息。

3.1.1接口设计

仔细检查控制器的描述，有四个对象较突出：Request，Response，RequestHandler，Controller，Controller接受Request，调度RequestHandler，然后返回Response对象。动手描述，你能编写一些简单的启动接口，就像Listing3.1所示。

Listing 3.1 Request，Response，RequestHandler，Controller interface

public interface Request{

String getName();

}

public interface Response{}

public interface RequestHandler{

Response process(Request request) throws Excepion;

}

public interface Controller{

Response processRequest(Request request);

void addHandler(Request request,RequestHandler requestHandler);

}

1.首先，定义一个Request接口，包含一个单独的getNmae方法，返回唯一请求名，因此你能区分每一个请求。因此你开发这个组件，你将需要其他的方法，但是你能添加他们当你进行编写时。

2.下一步，指定一个空接口，设计编码，你仅需要返回一个Response对象，Response包含的东西你能稍后处理。现在，你需要一个Response类型能插入一个签名。

3.下一步是定义一个RequestHandler接口，它能处理Request（请求）和返回你的Response（响应）。RequestHandler是一个辅助部件设计，执行大多的脏数据工作。它可能调用类抛出任何类型的异常。Exception是process方法抛出的。

4.定义一个顶层的方法来处理进入的请求。接受这个请求后，控制器发送它到合适的

RequestHandler上，通知processRequest不要声明任何异常，方法在栈顶能够捕获处理所有的内部错误。假如它不抛出一个异常，错误将常常进入Java Virtual Machine（JVM）或者servlet 容器中。JVM或者容器将然后出现用户使用的空白页中的一个。最好你为自己编码。

最后，控制器将是最好的设计元素，addHandler方法允许你继承Controller不用修改Java源代码。

设计模式实战：控制反转模式

一个简单的控制反转的例子是使用控制器注册一个处理程序。你可能知道这样一个模式，叫做好莱坞原则，“don't call us，we'll call you”。对象注册作为事件处理程序，当事件发生时，对已注册对象调用一个钩子方法，控制反转让架构管理事件生命周期同时，允许开发者给框架事件插入自定义的处理程序。

 

 

3.1.2实现基本类

继续采用LIsting3.1中的接口，Listing3.2展示一个简单控制器类的初稿。

Listing3.2 The generic Controller

[...]

import java.util.HashMap;

import java.util.Map;

public class DefaulController implements Controller{

private Map requestHandlers = new HashMap();

protected RequestHandler getHandler(Request request){

if(!this.requestHandler.containsKey(request.getNmae())){

String message = "Cannot find handler for request name" 

+ "[" + request.getName() + "]";

throw new RuntimeException(message);

}

return (RequestHandler) this.requestHandlers.get

(request.getName());

}

public Response processRequest(Request request){

Response response;

try{

response = getHandler(request).process(request);

}

catch (Exception exception){

response = new ErrorResponse(request,exception);

}

return response;

}

public void addHandler(Request request,RequestHander requestHandler){

if (this.requestHandlers.containsKey(request.getName())){

throw new RuntimeException("A request handler has " + 

"already been registered for request naem"

+ "[" + request. getName() + "]")

}

else{

this.requestHandlers.put(request.getName

(),requestHandler);

}

}

}

1.第一步，声明一个hashMap(java.util.HashMap)充当请求处理器的注册表。

2.下一步，添加一个protected方法，getHandler，获取给定请求的RequestHandler。

3.如果一个RequestHandler没有注册，将抛出一个RuntimeException

(java.lang.RuntimeExcption)异常,这是一个偶然事件表示成一个编程错误，而不是由用户或

者外部系统产生的问题。Java不需要你去使用方法签名声明RuntimeException。但是你依旧能作为异常捕获它。一个改进是将添加一个指定的异常给控制器框架(例如

NoSuitableRequestHandlerExceprion).

4.你的有效方法然后返回合适的处理器给它的调用者

5.processRequest方法是Controller类的核心，这个方法指派合适的处理器给请求和回传处理器的Response。假如一个异常产生，它将在ErrorResponse类中捕获，如Listing3.3所示。

6.最后，检查是否该处理程序的名称已注册。如果有的话然后抛出一个异常，看这个实现，请注意请求对象签名的次数。但是你仅仅使用它的名字，这种事情常常发生，当代码编写之前一个接口已经定义。一种方法去避免过度设计一个接口最好实践测试驱动开发（TDD）。

Lisiting3.3 Special responseclass signaling an error

[...]

public class ErrorResponse implements Response{

private Request origianlRequest;

private Exception originalException;

public ErrorResponse(Request request,Exception exception){

this.originalRequest = request;

this.originalException = exception;

}

public Request getOriginalRequest(){

return this.originalRequest;

}

public Exception getOriginalException(){

return this.originalException;

}

}

 

此时，你有一个粗糙但是有效的控制器骨架，表3.1展示上面这部分源代码如何要求。

Table3.1 Resolving the base requirements form the component

Requirement	Resolution
Accept requests	public Response processRequest(Request request)
Select handler	this.requestHandlers.get(request.getName())
Route requests	response=getRequestHandler(request).process(request);
Error handling	Cubclass ErrorResponse

 

对于许多开发者下一步将使用骨架控制器粗略地制作一个桩程序。作为测试注入开发者，我们能编写一个测试套件给控制器不用小题大做使用一个桩程序。这是单元测试之美，我们能编写一个包验证它是否工作，所有外部的常规Java应用。

3.2开始测试

合适的灵感让我们编写四个接口和两个开始类，假如我们现在不编写自动化测试，极限编程将找我们的麻烦。

列表3.2和列表3.3以一个简单的实现开始，我们在单元测试将做同样的事，我们可以探讨什么是尽可能简单的测试用例。

3.2.1测试DefaultController

DefaultController类的实例化的测试用例怎么实现，第一步在做任何有用的事是控制器构造它，因此我们开始，列表3.4展示引导测试代码，它构建DefaultController对象和设置测试框架。

Listing 3.4 TestDefaultController—a bootstrap iteration

[...]

import org.junit.core.Test;

import static org.junit.Assert.*;

public class TestDefaultController{

private DefaultController controller;

@Before

public void instantiate() throws Exception{

controller = new DefaultController();

}

@Test

public void testMethod(){

throw new RuntimeException("implement me");

}

}

1.测试类的名字需要以前缀Test开始，命名规则并不是必须的，但是一般都这么做，我们将类标记成测试类后，我们更容易地识别和在构建脚本中过滤它们。相对地，依赖你的本地语言，你可以更愿意使用Test作为类的前缀。

2.下一步，使用@Before注释实例化DefaultController的方法，这是JUnit框架调用测试方法之间的一个内建的扩展点。

3.插入一个虚拟的测试方法，以使有事件去运行。只要确认测试设施是工作的，你能开始添加真正的测试方法，虽然这个测试运行了，但是它依旧会失败，下一步将修补这个测试。

4.对还没有实现的测试代码最佳实践是抛出一个异常。它将阻止测试通过，提醒你必须实现这些代码。

现在你有一个引导测试，下一步决定首先测试什么。

JUnit’s details

@Before和@After注释方法在每一个@Test方法执行之前和之后执行，不管测试失败或通过，它帮助你提取所有的公共逻辑，像实例化你的领域对象和设置它们在一些已知的状态。

你可以有很多这些你想要的方法，但要注意你将有超过一个@Before和@After方法。它们的执行顺序是不用定义的。

JUnit也提供@BeforeClass和@AfterClass注释你的方法在类级别，这个方法将被执行一次，在所有你的@Test方法之前或之后。再次，就像@Before和@After注释一样，你可以有很多这些你想要的方法，它们的执行顺序是不用定义的。

你需要记住@Before/@After和@BeforeClass/@AfterClass注释方法必须设置成public，

@BeforeClass/@AfterClass注释方法必须设置成public和static。

3.2.2添加一个处理器

现在已有一个引导测试，下一步是决定首先测试什么。我们使用DefaultController对象开始测试用例，因为这是这个练习的重点：创建一个控制器。编写一些代码确定它编译成功，但是如何看测试是否运行呢？

控制器的目的是处理请求和返回响应。但是在处理请求之前，设计调用添加一个

RequestHandler去做处理工作，因此，第一件事首先是：你将测试是否能添加一个

RequestHandler。

在第一章中运行过这个测试和返回一个已知的结果。去看测试是否成功，你将比较期望值与测试对象的返回值是否一致，addHandler的签名是：

void addHandler(Request request,RequestHandler requestHandler)

添加一个RequestHandler，你需要一个已知的Request名字，去检查是否添加成功，你能使用DefaultController类中的getHandler方法，使用如下签名：

RequestHandler getHandler(Request request)

这样是可行的，因为getHandler方法访问权限是protected，测试类是位于同样的包中。这是一个原因去定义测试在同一个包下。

测试第一步，你能做如下事情：

n 添加一个RequestHandler，引用一个Request

n 取得一个RequestHandler和通过同样的Request

n 检查看是否得到同一个RequestHandler返回

n 测试来自哪里？

现在你知道你需要哪些对象，下一个问题是，“这些对象来自哪里？”，你因该向前并编写一些你将在应用中使用的对象。例如一个登录请求？

单元测试的重点是一次测试一个对象，在面向对象环境中，像Java，你设计对象同其它对象交互，创建一个单元测试，因此，你需要两种类型的对象：你测试的领域对象(domain object)和测试对象(test objects)同测试下的对象进行交互。

定义：DEFINITION

Domain object:在单元测试上下文中，就域对象而言，用于对比和比较应用程序中使用的对象和测试程序中使用的对象。在测试中任何对象被认为是一个域对象。

假如你需要另一个域对象，像登录请求，测试失败，罪魁祸首将很难确定，你可能不能去告诉这个问题是否是一个控制器或者请求，因此，在一系列测试的第一步，你将使用唯一的类是DefaultController，其它的一切将是指定的测试类。

JUnit最佳实践：单元测试的重点是一次测试一个对象

单元测试一个重要的方面是它们是细粒度的。单元测试独立检查你创建的每一个对象，这样只要问题发生就能隔离。假如你在测试中放置多个对象，你不能预测当改变发生时对象间如何交互，你可以在可预测的测试对象下测试对象，另一种软件测试形式，集成测试，检查对象之间的相互作用，第四章有更多关于其他类型的测试。

Where do test classes live？

测试类将放置在哪里？Java提供几个选择，如下其中的一个：

n 在包中将它们标记类成public

n 在测试类中将它们设置成内部类

如果类是简单的可能保持那种形式，它们很容易作为内部类去编写它们，这个类的实例很简单，Listing3.5演示内部类添加到TestDefaultController类中。

Listing3.5，Test classes as inner classes

public class TestDefaultController{

private class SampleRequest implements Request{

public String getName(){

return "Test";

}

}

private class SampleHandler implements RequestHandler{

public Response process(Request request) throws Exception{

return new SampleResponse();

}

}

private class SampleResponse implements Response{

//empty

}

}

1.首先，设置一个请求对象，返回已知的名字（Test）。

2.下一步，实现一个SampleHandler，接口调用process方法，因此你不得不那样编码。现在你没有测试process方法，因此它返回一个SampleResponse对象满足签名。继续定义一个空的SampleResponse以便可以实例化。

从Listing3.5中，我们看Listing3.6演示一个添加RequestHandler测试。

Listing3.6 TestDefaultController.tetAddHandler

[...]

import static org.junit.Assert.*;

public class TestDefaultController{

@Test

public void testAddHandler(){

Request request = new SampleRequest();

RequestHandler handler = new SampleHandler();

controller.addHandler(request,handler);

RequestHandler handler2 = conrtoller.getHandler(request);

assertSame("Hander we set in conrotller should be teh same 

handler we get",handler2,handler);

}

}

1.给测试方法设置一个明显的名字，使用@Test注释测试方法。

2.记住实例化测试对象

3.这段代码是测试的重点：Controller（测试下的对象）添加测试处理器，注意

DefaultController对象是被@Before注释的方法实例化的

4.在新的变量名下回读处理器

5.检查是否得到相同的对象

JUnit最佳实践：选择有意义的测试方法名

你能知道用@Test注释的方法是一个测试方法。你也必须通过阅读方法名字能理解它是一个测试方法。虽然JUnit没有要求任何特定的规则来命名测试方法，一个好的规则是使用testxxx结构开始命名测试方法，xxx是要测试域方法的名字。当你添加其它测试与相同的测试名冲突时，移动到testxxxyyy结构，yyy描述测试的不同之处。不要害怕你测试方法的名字过长或者冗长。你将在本章最后看到，有时不太明显，一个测试是测试方法通过查找它的断言方法时，命名你的测试方法使用一个描述性的方式，必要时添加注释。

虽然它简单，但是这个单元测试证实了关键的前提用于存储和检索RequestHandler的机制是灵活且好的。假如addHandler或者getRequest在将来失败了，测试将迅速地甄别问题所在。

像这样创建许多测试，你将注意以下模式：

1.将测试环境设置成一个已知的状态(创建对象，获得资源)。预测试状态参考test fixture(测试夹具)

2.调用测试下的方法

3.确认测试结果，常常调用一个或多个断言(assert)方法。

 

3.2.3处理一个请求

我们看看控制器的核心测试目标，处理请求。按照惯例，我们在Listing3.7展示这个测试并回顾它。

Listing3.7 testProceesRequest method

import static org.junit.Assert.*;

public class TestDefaultController{

[...]

@Test

public void testProcessRequest(){

Request request = new SampleRequest();

RequestHandler handler = new SampleHandler();

controller.addHandler(request,handler);

Response response = conroller.processRequest(request);

assertNotNull("Must not return a null response",response);

assertEquals("Response should be of type SampleResponse",

SampleResponse.class,response.getClass());

}

}

1.首先，使用@Test注释测试方法，然后给出测试取一个简单统一的名字

2.设置测试对象和添加测试处理器

3.Response对象代码从Listing3.6分离出来，然后调用processRequest方法

4.验证返回的Response对象是否为空。这很重要，因为你在Response对象上调用getClass方法，如果Response对象为空，它将验证失败，并抛出一个令人畏惧的空指向异常

(NullPointerException)，使用assertNotNull(Sring,Object)签名假如测试失败的话，错误显示是有意义和容易去理解的。但是如果使用assertNotNull(Object)签名，JUnit运行器能够显示一个栈跟踪java.lang.AssertionError异常而没有错误信息，这将使诊断更加困难。

5.最后，比较测试结果和期望结果(SampliResponse)是否一致。

 

JUnit最佳实践：在断言调用中解释失败原因

无论什么时候使用JUnit assert*方法，确认使用这样的签名形式，使用一个字符串(String)作为第一个参数，这个参数让你提供一个有意义的描述，假如断言失败的话显示Junit测试运行器信息，不要使用这样的参数，当失效发生时它很难去理解。

 

设置逻辑分解

因为两个测试做了同样的设置，你能复制代码进入@Before注释中，同一时刻，你又不想复制它到一个新的@Before方法中，因为你不确定将首先执行哪一个方法，可以得到一个异常。你能将代码移动到同样的@Before方法中。

随着你添加更过的测试方法，你可能需要调整如何做，在@Before方法中，现在，排除重复的代买尽可能帮助你编写更多的测试。Listing3.8,显示改进的TestDefaultController类，改近的地方以粗体显示。

Listing3.8 TestDefaultController After some refactoring

[...]

public class TestDefaultController{

private DefaultController controller;

private Request request; 

private RequestHandler handler;

@Before

public void initialize()throws Exception{

controller = new DefaultController();

request = new SampleRequest();

handler = new Samplehandler();

controller.addHandler(request,handler);

}

private class SampleRequest implements Request{

//Same as in listing 3.1

}

private class SampleHandler implements RequestHandler{

//Same as in listing 3.1

}

private class SampleResponse implements Response{

//Same as in listing 3.1

}

@Test

public void testAddHandler(){

RequestHandler handler2 = controller.gethandler(request);

assertSame(handler2,handler);

}

@Test

public void testProcessRequest(){

Response response =controller.processRequest(request);

assertNotNull("Must not return a null response",response);

assertEquals("response should be of type 

 

SampleResponse",SampleResponse.class,response.getClass());

}

}

1.我们移动测试Request和RequestHandler对象的初始化到initialize()方法中。

2.initialize()保存着testAddhandler和testProcessRequest中的重复代码。

3.因此，我们编写一个新的@Before注释方法以便添加处理器到控制器，因为@Before方法在每个单独@Test方法之前执行，我们确认我们完整地设置了DefaultConroller对象。

定义(definition):代码重构Refactor，改进已存在代码的设计。

 

注意在一个测试方法中，不要试图通过测试多个操作去共享设置代码，如Listing3.9所示。

Listing3.9 Anti-example:don't conbine test methods.

public class TestDefaultController{

@Test

public void tetsADdAndProcess(){

Request request = new SampleRequest();

Requesthandler handler = new Samplehandler();

controller.addhandler(request,handler);

RequestHandler handler2 = controller.gerhandler(request);

assertEquals(handler2,handler);

// DO NOT COMBINE TEST METHODS THIS WAY

Response response = conrtoller.processRequest(request);

assertNotNull("Must not return a null response",response);

assertEquals(SampleResponse.class,response.getCalss());

}

}

 

JUnit最佳实践：一个单元测试对应一个@Test方法

不要将多个测试塞入一个方法中。这将导致测试方法复杂化，变得越来越难以阅读和理解。更糟糕的是，测试方法中会有更过的逻辑，将增加不运行和调试的风险，滑坡将结束鞭子额测试来测试你的测试。

在程序中，当出现工作或者失败的时候，单元测试将给你信心，如果将多个单元测试放入一个测试方法中，它将变得更加困难地观察哪里出错。当测试共享同样的方法时，一个失败的测试会使夹具处于可预知的状态。在方法中其它的测试嵌入可能不会运行或者正确的运行，你的测试结果的图片通常是不完整的或误导的。

因为所有的测试方法在一个测试类中共享同样的夹具，JUnit能产生一个自动的测试套件，它很容易地替换每一个单元测试用它们自己的方法。假如你需要使用同样的代码块在多个测试间，把它们提取成一个实用方法，每一个测试方法都能调用它，更好地，假如所有的方法能共享代码，将它放入到夹具中。

另外常用的陷阱是编写测试方法并不包含断言声明，当你执行这些测试时，观察JUnit标记它们成功，但这是一个成功测试的假象，总是使用断言调用。只有一种情况不使用断言是可以接受的，当一个异常抛出表示一个错误条件时。

为了更好的结果，你的测试方法应当简明地、集中你的域方法。每个测试方法必须尽可能地清晰和集中，这就是为什么JUnit提供使用@Before，@After，@AfterClass，@BeforeClass注释：因此你能共享夹具而不用组合测试方法。

3.2.4改进testPeocessRequest

在Listing3.7中编写testProcessRequest方法时，我们希望响应返回的值是期望的回应，实现确认返回的对象是我们期望的对象。但是我们希望知道的是返回的响应是否与期望的响应相等。

这个响应可能是一个不同的类，重要的是这个类识别他自己是正确的响应。

assertSame方法确认两个引用是同一个对象，assertEquals方法同equals方法一样。从基类

Object继承而来，如果两个不同的对象有同样的身份，需要提供自己定义的ID。对于像一个响应对象，你能指派每个响应它自己的令牌。

空实现的SampleResponse没有名字属性可以测试，为了得到想要的测试，不得不首先实现更多的Response类。Listing3.10展示加强的SampleResponse类。

Listing3.10 A refactored SampleResponse

public class TestDefaultController{

private class SampleResponse implements Resonse{

private static final String NAME = "Test";

public String getName(){

return NAME;

}

public boolean equals(Object object){

boolean result = false;

if (object instanceof SampleREsponse){

result = ((SampleResponse) object).getName().equals(getName());

}

return result;

}

public  int hashCode(){

return NAME.hashCode();

}

}

}

现在SampleResponse有一个身份（表现getName（））和它自己equals方法，你能修改这个测试方法。

@Test

public void testPeocessRequest(){

Response response = controller.processRequest(request);

assertNotNull("Must not return a null response",response);

assertEquals(new SampleREsponse(),response);

}

我们使用SampleResponse类介绍身份的概念在测试中的目的。但是测试告诉你应该有存在合适的Response类，你需要修改Response接口如下；

public interface Response{

String getName();

}

就像你看到这样，测试能告诉或者指导你一个好的设计，但是这不是测试真正的目的，不要忘记测试常常用于保护我们在代码中介绍错误。这样做我们需要测试每一个条件，在我们应用可执行的情况下，我们开始探讨异常条件在下一章中。