Introduction Test-Driven Development EasyMock Example Summary

Test-driven Development using JUnit andEasyMock

Developer’s Day 2010

Patrick Schlebusch

Chair of Computer Science 5 - Information Systems

October 5, 2010

1 / 17

Introduction Test-Driven Development EasyMock Example Summary

Overview

1 Introduction

2 Test-Driven Development

3 EasyMock

4 Example

5 Summary

2 / 17

Introduction Test-Driven Development EasyMock Example Summary

Why Testing?

testing is usually not a popular task→ affects quality of tests

testing is necessary→ you will have to it anyway

but: testing is not so bad, if you use the right tools

3 / 17

Introduction Test-Driven Development EasyMock Example Summary

Testing Basics

What is testing?→ checking actual behavior against specified/expected behavior

Why do we test?

finding bugsestablishing confidence & trust in the software

kinds of testing:

black-box: without knowledge of internal structurewhite-box: with knowledge of internal structure

types of tests:

unit testintegration testsystem test

4 / 17

Introduction Test-Driven Development EasyMock Example Summary

Motivation

developers spend too much time debugging

writing tests afterwards causes problems:

it is tedious (”it works, so why bother?”)no independence→ low quality of tests (the code does, what the code does)

independence is important for tests, but often notincorporated

losing focus on the requirements during development

5 / 17

Introduction Test-Driven Development EasyMock Example Summary

Concepts

Drawing: Tim Ottinger

evolutionary test and implementation

always write the test before the code and let it fail first

fast, automated tests that can be run frequently

6 / 17

Introduction Test-Driven Development EasyMock Example Summary

Pros & Cons

noticing defects right when they are introduced→ much less time spent debugging

if followed strictly, a very high test coverage is achieved→ higher quality, less undiscovered bugs

design and code will be more testable

forces the developer to think about the requirements beforeeach change

hard to learn

tests need to be maintained too

thorough unit tests cannot replace integration & system tests

7 / 17

Introduction Test-Driven Development EasyMock Example Summary

What is Mocking?

we want to test units in isolation

to be able to locate errors easilybut: most units communicate with other units

create a test environment to simulate behavior of other units

verify when, where and which data is passed by a unit

mock-objects

contain no functionality, but can return test valuesallow verifying called methods, parameters, etc.

8 / 17

Introduction Test-Driven Development EasyMock Example Summary

EasyMock

Open Source Mocking framework for Java

available from http://easymock.org

first presented at OOPSLA 2001

dynamically creates mock objects from classes and interfaces

provides methods for specifying and verifying expectations andstub behavior

much more convenient than hand-written mocks/stubs

9 / 17

Introduction Test-Driven Development EasyMock Example Summary

Mock Types

Mock

only explicitly specified calls are expectedorder of calls is not verified

NiceMock

calls that are not expected don’t fail the testunexpected calls return default null valuesorder of calls is not verified

StrictMock

only explicitly specified calls are expectedorder of calls is verified

Partial mock

only some methods are mockedobject can still contain functionality in some methods

10 / 17

Introduction Test-Driven Development EasyMock Example Summary

Defining Expectations

after creation the Mock is in record-mode

all calls made to this object will be recorded as expectations

methods expect and expectLastCall can be used

to specify a return value or exception to be thrownto specify how often this call should be expected

but: should be used carefully, otherwise implementation isrestricted too much

11 / 17

Introduction Test-Driven Development EasyMock Example Summary

Replaying and Verifying Mocks

after recording expected calls, mocks can be set to replay state

in replay state mocks behaves as defined for the test

after the test, mocks can be verified

checks whether all expected calls happened

if not, the test fails

12 / 17

Introduction Test-Driven Development EasyMock Example Summary

Matchers and Captures

when specifying behavior you might not know parametervalues of method calls→ Matchers

matchers allow matching parameter values

for example by class or valuecan be combined (and, or, not)own matchers can be implemented

you might want to intercept passed parameters to inspectthem→ Captures

captures allow capturing parameters that are passed to themock

13 / 17

Introduction Test-Driven Development EasyMock Example Summary

Limitations of EasyMock

some technical limitations:

mocking of final methods is not possiblemocking of private methods is not possiblemocking of static methods is not possible

unfortunately fail/error messages are often misleading

14 / 17

Introduction Test-Driven Development EasyMock Example Summary

Example Demonstration

15 / 17

Introduction Test-Driven Development EasyMock Example Summary

Summary

TDD helps writing better tests

takes the tediousness out of testing

still requires commitment

mocking is a practical tool for Unit-testing

especially useful for TDD

mocking has (technical) limitations

should be used responsibly!

16 / 17

Introduction Test-Driven Development EasyMock Example Summary

Thanks..

Thank you for your attention!

17 / 17