《xUnit Test Patterns》学习笔记5 - xUnit基础

这几节我看的比较快一些,因为内容之间其实是有联系的,所以合在一起做一个笔记。6-10节主要介绍了什么是Fixture,如何保证一个Fresh Fixture,如何使用Setup,Tearndown,如何进行验证(Verify),等等。

什么是Fixture?

The test fixture is everything we need to have in place to exercise the SUT.

从作者的英文解释来看,Fixture确实是一个比较难定义的东西,所以作者用了everything这个词。

什么是Fresh Fixture?

一个测试案例一般都包含以下几个步骤:

  1. Setup
  2. Exercise
  3. Verify
  4. Teardown

Fresh Fixture是指每个案例执行时,都会生成一个全新的Fixture,好处是不受其他案例的影响。避免了Interacting Tests(之前有提到的)。

image

什么是Setup?

Setup是案例的准备阶段,主要有三种实现方式:In-line Fixture Setup, Delegated Setup, Implicit Setup。推荐使用的是Implicit Setup。

In-line Fixture Setup

直接在测试方法内部做一些具体的Setup操作 :

public void testStatus_initial() {
      
// In-line setup
      Airport departureAirport = new Airport("Calgary""YYC");
      Airport destinationAirport 
= new Airport("Toronto""YYZ");
      Flight flight 
= new Flight( flightNumber,
                                 departureAirport,
                                 destinationAirport);
      
// Exercise SUT and verify outcome
      assertEquals(FlightState.PROPOSED, flight.getStatus());
      
// tearDown:
      
//    Garbage-collected
}

缺点是容易造成很多重复的代码,不易维护。

Delegated Setup

相比In-line Fixture Setup,将里面具体的Setup操作提取出来,作为一个公用的方法,提高了复用性。

public void testGetStatus_inital() {
       
// Setup
      Flight flight = createAnonymousFlight();
      
// Exercise SUT and verify outcome
      assertEquals(FlightState.PROPOSED, flight.getStatus());
      
// Teardown
      
// Garbage-collected
}


Implicit Setup

几乎所有的xUnit家族的框架都支持SetUp,比如,使用Google Test中指定的函数名SetUp,NUnit使用[Setup]Attribute。这种方法,不需要我们自己去调用Setup方法,框架会在创建Fresh Fixture后调用Setup。因此,我们只管实现SetUp方法。

Airport departureAirport;
Airport destinationAirport;
Flight flight;
public void testGetStatus_inital() {
   
// Implicit setup
   
// Exercise SUT and verify outcome
   assertEquals(FlightState.PROPOSED, flight.getStatus());
}
public void setUp() throws Exception{
   
super.setUp(); 
   departureAirport 
= new Airport("Calgary""YYC");
   destinationAirport 
= new Airport("Toronto""YYZ");
   BigDecimal flightNumber 
= new BigDecimal("999");
   flight 
= new Flight( flightNumber , departureAirport,
                           destinationAirport);
}


什么是Teardown?

为了保证每个案例都拥有一个Fresh Fixture,必须在案例的结束时做一些清理操作,这就是Teardown。和Setup一样,Teardown也有三种实现方式:In-line Fixture Teardown, Delegated Teardown, Implicit Teardown。同样,推荐使用Implicit Teardown。

image


什么是Shared Fixture?

多个测试方法共用一个Fixture,这时,Setup只会在第一个测试方法执行时被执行。gtest中,同时还拥有一个公共的TearDownTestCases方法。

image


Result Verification

前面说过,测试案例必须拥有Self-Checking的能力。Verification分两种:State Verification和Behavior Verification。

State Verification

执行SUT后,验证SUT的状态:

image

验证时,可以使用Build-in Assertions,比如xUnit框架提供的assertTrue, assertEquals等方法。或者Custom Assertion等等。

Behavior Verification

不仅仅验证SUT的状态,同时还对SUT的行为对外部因素造成的影响进行验证。

image

比如下面这个例子:

public void testRemoveFlightLogging_recordingTestStub()
            
throws Exception {
      
// fixture setup
      FlightDto expectedFlightDto = createAnUnregFlight();
      FlightManagementFacade facade 
=
            
new FlightManagementFacadeImpl();
      
//    Test Double setup
      AuditLogSpy logSpy = new AuditLogSpy();
      facade.setAuditLog(logSpy);
      
// exercise
      facade.removeFlight(expectedFlightDto.getFlightNumber());
      
// verify
      assertEquals("number of calls"1,
                   logSpy.getNumberOfCalls());
      assertEquals(
"action code",
                   Helper.REMOVE_FLIGHT_ACTION_CODE,
                   logSpy.getActionCode());
      assertEquals(
"date", helper.getTodaysDateWithoutTime(),
                   logSpy.getDate());
      assertEquals(
"user", Helper.TEST_USER_NAME,
                   logSpy.getUser());
      assertEquals(
"detail",
                   expectedFlightDto.getFlightNumber(),
                   logSpy.getDetail());
}

除此之外,我们还可以使用一些Mock框架,使用基于行为的验证方式,这种方式,不需要我们显式的调用验证的方法。(Expected Behaivor Specification)

public void testRemoveFlight_JMock() throws Exception {
      
// fixture setup
      FlightDto expectedFlightDto = createAnonRegFlight();
      FlightManagementFacade facade 
=
            
new FlightManagementFacadeImpl();
      
// mock configuration
      Mock mockLog = mock(AuditLog.class);
      
mockLog.expects(once()).method("logMessage")
               .with(eq(helper.getTodaysDateWithoutTime()),
                     eq(Helper.TEST_USER_NAME),
                     eq(Helper.REMOVE_FLIGHT_ACTION_CODE),
                     eq(expectedFlightDto.getFlightNumber()));
      
// mock installation
      facade.setAuditLog((AuditLog) mockLog.proxy());
      
// exercise
      facade.removeFlight(expectedFlightDto.getFlightNumber());
      
// verify
      
// verify() method called automatically by JMock
}


如何使测试代码变得简洁,减少重复?

Expected Object

需要比较对象内部很多属性时,使用对象比较会更简单。

原有案例代码:

public void testInvoice_addLineItem7() {
      LineItem expItem 
= new LineItem(inv, product, QUANTITY);
      
// Exercise
      inv.addItemQuantity(product, QUANTITY);
      
// Verify
      List lineItems = inv.getLineItems();
      LineItem actual 
= (LineItem)lineItems.get(0);
      assertEquals(expItem.getInv(), actual.getInv());
      assertEquals(expItem.getProd(), actual.getProd());
      assertEquals(expItem.getQuantity(), actual.getQuantity());
}

改进后:

public void testInvoice_addLineItem8() {
      LineItem expItem 
= new LineItem(inv, product, QUANTITY);
      
// Exercise
      inv.addItemQuantity(product, QUANTITY);
      
// Verify
      List lineItems = inv.getLineItems();
      LineItem actual 
= (LineItem)lineItems.get(0);
      
assertEquals("Item", expItem, actual);
}

 

Custom Assersions

需要验证的细节很多时,可以自己定义一个Assersion,隐藏掉这些细节。比如:

static void assertLineItemsEqual(
                     String  msg, LineItem exp, LineItem act) {
      assertEquals (msg
+" Inv",  exp.getInv(), act.getInv());
      assertEquals (msg
+" Prod", exp.getProd(), act.getProd());
      assertEquals (msg
+" Quan", exp.getQuantity(), act.getQuantity());
}

 

Verification Methods

和Custom Asserions很像,唯一不同的是,Custom Assertion只包含验证的代码,Verification Methods同时还包含对SUT的操作。比如:

void assertInvoiceContainsOnlyThisLineItem(
                                     Invoice inv,
                                     LineItem expItem) {
      
List lineItems = inv.getLineItems();
      assertEquals(
"number of items", lineItems.size(), 1);
      LineItem actual 
= (LineItem)lineItems.get(0);
      assertLineItemsEqual(
"",expItem, actual);
}

 

Parameterized and Data-Driven Tests

对于测试逻辑一致,只是测试数据有不同的测试案例,适合使用参数化测试,或者叫数据驱动测试。比如,Google Test就很好的提供了参数化的测试,见:

玩转 Google开源C++单元测试框架Google Test系列(gtest)之四 - 参数化

通过参数化,可以简化测试代码,不需要为大量不同的输入数据分别编写测试案例。

Avoiding Conditional Test Logic

验证时,不要使用一些条件相关的逻辑!比如,不要使用if, loop之类的语句!下面是一个例子:

使用if的情况:

List lineItems = invoice.getLineItems();
if (lineItems.size() == 1) {
   LineItem expected 
=
      
new LineItem(invoice, product,5,
                   
new BigDecimal("30"),
                   
new BigDecimal("69.96"));
   LineItem actItem 
= (LineItem) lineItems.get(0);
   assertEquals(
"invoice", expected, actItem);
else {
   fail(
"Invoice should have exactly one line item");
}

可以看出,上面的写法是不好的,验证中有逻辑判断意味着有可能案例不够单一,使得案例难以理解。因此,比较好的是改成下面的方式:

List lineItems = invoice.getLineItems();
assertEquals("number of items", lineItems.size(), 1);
LineItem expected 
=
   
new LineItem(invoice, product, 5,
                
new BigDecimal("30"),
                
new BigDecimal("69.96"));
LineItem actItem 
= (LineItem) lineItems.get(0);
assertEquals(
"invoice", expected, actItem);

 

Working Backward

一个编写测试案例的小技巧或者说是习惯吧,就是实现一个测试案例时,从最后一行开始写起,比如,先写Assertions。可以一试。

Using Test-Driven Development to Write Test Utility Method

我们经常实现一些测试用的辅助方法,这些方法在实现过程中,使用TDD的方式去实现,编写一些简单的测试案例,保证辅助方法也是正确的。也就是说,测试案例代码本身也是需要被测试的。

posted @ 2010-01-24 17:13  CoderZh  阅读(10453)  评论(1编辑  收藏  举报