My talk on TDD using JUnit and EasyMock for Developer's Day 2010 @ I5.

1. Introduction Test-Driven Development EasyMock Example Summary
Test-driven Development using JUnit and
EasyMock
Developer’s Day 2010
Patrick Schlebusch
Chair of Computer Science 5 - Information Systems
October 5, 2010
1 / 17

2. Introduction Test-Driven Development EasyMock Example Summary
Overview
1 Introduction
2 Test-Driven Development
3 EasyMock
4 Example
5 Summary
2 / 17

3. 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

4. Introduction Test-Driven Development EasyMock Example Summary
Testing Basics
What is testing?
→ checking actual behavior against specified/expected behavior
Why do we test?
finding bugs
establishing confidence & trust in the software
kinds of testing:
black-box: without knowledge of internal structure
white-box: with knowledge of internal structure
types of tests:
unit test
integration test
system test
4 / 17

5. 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 not
incorporated
losing focus on the requirements during development
5 / 17

6. 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

7. 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 before
each change
hard to learn
tests need to be maintained too
thorough unit tests cannot replace integration & system tests
7 / 17

8. Introduction Test-Driven Development EasyMock Example Summary
What is Mocking?
we want to test units in isolation
to be able to locate errors easily
but: 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 values
allow verifying called methods, parameters, etc.
8 / 17

9. 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 and
stub behavior
much more convenient than hand-written mocks/stubs
9 / 17

10. Introduction Test-Driven Development EasyMock Example Summary
Mock Types
Mock
only explicitly specified calls are expected
order of calls is not verified
NiceMock
calls that are not expected don’t fail the test
unexpected calls return default null values
order of calls is not verified
StrictMock
only explicitly specified calls are expected
order of calls is verified
Partial mock
only some methods are mocked
object can still contain functionality in some methods
10 / 17

11. 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 thrown
to specify how often this call should be expected
but: should be used carefully, otherwise implementation is
restricted too much
11 / 17

12. 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

13. Introduction Test-Driven Development EasyMock Example Summary
Matchers and Captures
when specifying behavior you might not know parameter
values of method calls
→ Matchers
matchers allow matching parameter values
for example by class or value
can be combined (and, or, not)
own matchers can be implemented
you might want to intercept passed parameters to inspect
them
→ Captures
captures allow capturing parameters that are passed to the
mock
13 / 17

14. Introduction Test-Driven Development EasyMock Example Summary
Limitations of EasyMock
some technical limitations:
mocking of final methods is not possible
mocking of private methods is not possible
mocking of static methods is not possible
unfortunately fail/error messages are often misleading
14 / 17

15. Introduction Test-Driven Development EasyMock Example Summary
Example Demonstration
15 / 17

16. 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

17. Introduction Test-Driven Development EasyMock Example Summary
Thanks..
Thank you for your attention!
17 / 17