Unit Testing

using JUnit
INF5750/9750 - Lecture 4 (Part II)
 Problem area
● Code components must be tested!
○ Confirms that your code works
● Components must be tested in isolation
○ A functional test can tell you that a bug exists in the
implementation
○ A unit test tells you where the bug is located

Test failure!
Component A But where
is the bug?
<using> <using>

Component B Component C
 Example: The Calculator
public interface Calculator
{
int add( int number1, int number2 );

int multiply( int number1, int number2 );

}

public class DefaultCalculator

implements Calculator
{
public int add( int number1, int number2 )
{
return number1 + number2;
}

public int multiply( int number1, int number2 )

{
return number1 * number2;
}
}
 Approaches to unit testing
● Write a small command-line program, enter values, and
verify output
○ Involves your ability to type numbers
○ Requires skills in mental calculation
○ Doesn’t verify your code when its released
 Approaches to unit testing
● Write a simple test program
○ Objective and preserves testing efforts
○ Requires you to monitor the screen for error messages
○ Inflexible when more tests are needed
public class TestCalculator
{
public static void main( String[] args )
{
Calculator calculator = new DefaultCalculator();

int result = calculator.add( 8, 7 );

if ( result != 15 )
{
System.out.println( ”Wrong result: ” + result );
}
}
}
 The preferred solution
● Use a unit testing framework like JUnit
○ A unit is the smallest testable component in an
application
○ A unit is in most cases a method
○ A unit does not depend on other components which
are not unit tested themselves
○ Focus on whether a method is following its API
contract

Component A Unit test A

<using> <using>

Unit test B Component B Component C Unit test C

 JUnit
● De facto standard for developing unit tests in Java
○ One of the most important Java libraries ever developed
○ Made unit testing easy and popular among developers
○ Driven by annotations
○ Spring provides integration with JUnit
 Using JUnit annotations
● No need to follow naming conventions
○ Tests identified by @Test annotation
○ Fixture methods identified by @Before and @After
annotations

● Class-scoped fixture
○ Identified by @BeforeClass and @AfterClass annotations
○ Useful for setting up expensive resources, but be careful…

● Ignored tests
○ Identified by @Ignore annotation
○ Useful for slow tests and tests failing for reasons beyond you

● Timed tests
○ Identified by providing a parameter @Test(timeout=500)
○ Useful for benchmarking, network, deadlock testing
 Test fixtures
● Tests may require common resources to be set up
○ Complex data structures
○ Database connections

● A fixture is a set of common needed resources

○ A fixture can be created by overriding the setUp and
tearDown methods from TestCase
○ setUp is invoked before each test, tearDown after

TestCase
lifecycle
setUp() testXXX() tearDown()
 JUnit Calculator test
import static junit.framework.Assert.*;
Static import of Assert
public class CalculatorTest
{
Calculator calculator;

Fixture
@Before
public void before()
{
Fixture calculator = new DefaultCalculator();
}

@Test
public void addTest()
{
Use assertEquals to
int sum = calculator.add( 8, 7 );
verify output assertEquals( sum, 15 );
}

@Test
public void multiplyTest()
{
}
}
 Example: The EventDAO
public class Event()
Event object {
private int id;
private String title;
private Date date;

// constructors
// get and set methods
}

public interface EventDAO

EventDAO interface {
int saveEvent( Event event );

Event getEvent( int id );

void deleteEvent( Event event );

}
 EventDAOTest
import static junit.framework.Assert.assertEquals;
Assert imported statically
@Before
public void init()
Fixture method identified {
by the @Before annotation eventDAO = new MemoryEventDAO();
event = new Event( ”U2 concert”, date );
}

@Test
public void saveEvent()
Test identified by the @Test {
int id = eventDAO.saveEvent( event );
annotation. Test signature is
equal to method signature.
event = eventDAO.getEvent( id );

assertEquals( id, event.getId() );

}

Test being ignored @Test @Ignore

Public void getEvent()
{
// Testing code...
}
 The Assert class
● Contains methods for testing whether:
○ Conditions are true or false
○ Objects are equal or not
○ Objects are null or not

● If the test fails, an AssertionFailedError is thrown

● All methods have overloads for various parameter types
● Methods available because TestCase inherits Assert
Assert
<inherits>

TestCase
<inherits>

EventDAOTest
 Assert methods
Method Description

assertTrue( boolean ) Asserts that a condition is true.

assertFalse( boolean ) Asserts that a condition is false.

assertEquals( Object, Object ) Asserts that two objects are equal.

assertArrayEquals ( Object[], Object[] ) Asserts that all elements in the two arrays are equal

assertNotNull( Object ) Asserts that an object is not null.

assertNull( Object ) Asserts that an object is null.

assertSame( Object, Object ) Asserts that two references refer to the same object.

assertNotSame( Object, Object ) Asserts that two references do not refer to the same object.

fail( String ) Asserts that a test fails, and prints the given message.
 Assert in EventDAOTest

@Test
public void testSaveEvent()
{
Asserts that the saved object is int id = eventDAO.saveEvent( event );
event = eventDAO.getEvent( id );
equal to the retrieved object
assertEquals( id, event.getId() );
assertEquals( ”U2 concert”, event.getTitle() );
}

Saves and retrieves an Event

with the generated identifier @Test
public void testGetEvent()
{
int id = eventDAO.saveEvent( event );
event = eventDAO.getEvent( id );
An object is expected assertNotNull( event );
event = eventDAO.getEvent( -1 );
assertNull( event );
}
Asserts that null is returned
when no object exists
Core Hamcrest Matchers - assertThat
Examples The matchers

allOf(...) - same as && (AND)

assertThat("good", allOf(equalTo("good"), startsWith("good"))); equalTo(...) - object equivalence,
startsWith(...) - string matching

assertThat("good", not(allOf(equalTo("bad"), equalTo("good")))); not(...) - same as != (NOT EQUAL)

assertThat("good", anyOf(equalTo("bad"), equalTo("good"))); anyOf (...) - same as || (OR)

assertThat(theBiscuit, equalTo(myBiscuit));
assertThat(theBiscuit, is(equalTo(myBiscuit))); is - syntactic sugar - all 3 statements are same
assertThat(theBiscuit, is(myBiscuit));

● Don’t use too much sugar!! - Only use for readability

 Testing Exceptions
● Methods may be required to throw exceptions
● Expected exception can be declared as an annotation
○ @Test( expected = UnsupportedOperationException.class )

Annotation declares that an @Test( expected = UnsupportedOperationException.class )

exception of class public void divideByZero()
UnsupportedOperationException {
is supposed to be thrown calculator.divide( 4, 0 );
}
 Running JUnit
● Textual test runner
○ Used from the command line
○ Easy to run

● Integrated with Eclipse

○ Convenient, integrated testing within your development
environment!

● Integrated with Maven

○ Gets included in the build lifecycle!
 JUnit with Eclipse
● Eclipse features a JUnit view
● Provides an informative GUI displaying test summaries
● Lets you edit the code, compile and test without leaving
the Eclipse environment
 JUnit with Maven
● Maven provides support for automated unit testing with
JUnit
● Unit testing is included in the build lifecycle
○ Verifies that existing components work when other components
are added or changed

<dependency>
<groupId>junit</groupId>
Add dependency <artifactId>junit</artifactId>
to POM to put <version>4.11</version>
JUnit on the classpath <scope>test</scope>
</dependency>

Execute the Maven

$ mvn test
test phase
 JUnit with Maven
● Maven requires all test-class names to contain Test
● Standard directory for test classes is src/test/java
● The test phase is mapped to the Surefire plugin
● Surefire will generate reports based on your test runs
● Reports are located in target/surefire-reports
 Spring test support
● Spring has excellent test support providing:
○ IoC container caching
○ Dependency injection of test fixture instances / dependencies
○ Transaction management and rollback

● Spring (spring-test) integrates nicely with JUnit

1) Defines underlying test @RunWith(SpringJUnit4ClassRunner.class)

framework //@ContextConfiguration //this will look for a file EventDaoTest-context.xml
@ContextConfiguration(locations={"classpath*:/META-INF/beans.xml"})
@Transactional
2) Defines location of Spring
public class EventDaoTest
config file {
@Autowired
3) Makes class for Private EventDao eventDao;
transactional testing
@Test
public void testSaveEvent( Event event )
{
Autowires dependencies }
}
Unit Testing Spring MVC Controllers
● To test your Spring MVC Controllers, use
ModelAndViewAssert combined with
MockHttpServletRequest, MockHttpSession, and so on from
the org.springframework.mock.web package
1. Instantiate
Controller and
inject mock/stub
Controller
dependencies

Server-side Client-side

2. Execute with the 3. Create client with

WebApplicationContext RESTTemplate and see
and ResponseBody actual data
 Spring MVC - Server-side
● Due to autowiring, find the correct @WebAppConfiguration
● MockMvc class provides testing methods for method,
headers, request, response etc.
● standaloneSetup will create WebApplicationContext with
default Spring configuration for a webapp
With full Web Application Spring Configuration With controller-specific setup (more unit-like)
@RunWith(SpringJUnit4ClassRunner.class)
@WebAppConfiguration
@ContextConfiguration("my-servlet-context.xml")
public class MyWebTests { public class MyWebTests {

@Autowired private MockMvc mockMvc;

private WebApplicationContext wac;
@Before
private MockMvc mockMvc; public void setup() {
this.mockMvc = MockMvcBuilders.standaloneSetup(
@Before new AccountController()).build();
public void setup() { }
this.mockMvc = // ...
MockMvcBuilders.webAppContextSetup(this.wac).build(); }
}
// ...
}
 MockMvc usage
● perform() - does requests
@Test
public void testReadId() throws Exception {
this.mockMvc.perform(get("/read/1")
.accept(MediaType.parseMediaType("text/html;charset=UTF-8")))
.andExpect(status().isOk())
.andExpect(content().contentType("text/html"))
.andExpect(message.value("Message number 1 was hello"));
}

● model() - access the returned model

● status() - for HTTP Status
● accept() - accept mime type
● For repeated actions, in standalone setup you can:

standaloneSetup(new BaseController()) {
.alwaysExpect(status().isOk())
.alwaysExpect(content().contentType("application/json;charset=UTF-8"))
.build()
}
 Best practices
● One unit test for each tested method
○ Makes debugging easier
○ Easier to maintain
● Choose descriptive test method names
○ TestCase: Use the testXXX naming convention
○ Annotations: Use the method signature of the tested method
● Automate your test execution
○ If you add or change features, the old ones must still work
○ Also called regression testing
● Test more than the ”happy path”
○ Out-of-domain values
○ Boundary conditions
 Advantages of unit testing
● Improves debugging
○ Easy to track down bugs
● Facilitates refactoring
○ Verifies that existing features still work while changing the code
structure
● Enables teamwork
○ Lets you deliver tested components without waiting for the
whole application to finish
● Promotes object oriented design
○ Requires your code to be divided in small, re-usable units
● Serving as developer documentation
○ Unit tests are samples that demonstrates usage of the API
 Mocking Tests...

● We deliberately skip mocking in this course

● And integration tests
● Results in faster testing of the whole
system

● Not because we think its not useful, but

limitation of time
 Resources

● Vincent Massol: JUnit in Action

○ Two free sample chapters
○ http://www.manning.com/massol

● JUnit home page (www.junit.org)

○ Articles and forum

● Spring documentation chapter 11

○ http://docs.spring.io/spring/docs/3.2.x/spring-
framework-reference/html/testing.html