Test-Driven iOS Development pptx

www.it-ebooks.info
Test Driven
www.it-ebooks.info

www.it-ebooks.info
Test Driven
PRACTICAL TDD AND ACCEPTANCE TDD
FOR JAVA DEVELOPERS
LASSE KOSKELA
MANNING
Greenwich
(74° w. long.)
www.it-ebooks.info
For online information and ordering of this and other Manning books, please visit
www.manning.com. The publisher offers discounts on this book when ordered in quantity.
For more information, please contact:
Special Sales Department
Manning Publications Co.
Sound View Court 3B fax: (609) 877-8256
Greenwich, CT 06830 email:
©2008 by Manning Publications Co. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in
any form or by means electronic, mechanical, photocopying, or otherwise, without prior written
permission of the publisher.
Many of the designations used by manufacturers and sellers to distinguish their products are
claimed as trademarks. Where those designations appear in the book, and Manning
Publications was aware of a trademark claim, the designations have been printed in initial caps
or all caps.
Recognizing the importance of preserving what has been written, it is Manning’s policy to have
the books we publish printed on acid-free paper, and we exert our best efforts to that end.
Manning Publications Co. Copyeditor: Laura Merrill

Sound View Court 3B Typesetter: Gordan Salinovic
Greenwich, CT 06830 Cover designer: Leslie Haimes
ISBN 1-932394-85-0
Printed in the United States of America
12345678910–MAL –13121110090807
www.it-ebooks.info
To my colleagues,
for bugging me to finish this project.

And to my love Lotta,
who gave me the energy to do it.
www.it-ebooks.info

www.it-ebooks.info
vii
brief contents
PART 1 A TDD PRIMER 1
1 ■ The big picture 3
2
■ Beginning TDD 43
3
■ Refactoring in small steps 75
4
■ Concepts and patterns for TDD 99

PART 2APPLYING TDD
TO SPECIFIC TECHNOLOGIES 151
5 ■ Test-driving web components 153
6
■ Test-driving data access 195
7
■ Test-driving the unpredictable 249
8
■ Test-driving Swing 279
www.it-ebooks.info
viii BRIEF CONTENTS
PART 3BUILDING PRODUCTS
WITH ACCEPTANCE TDD 321
9 ■ Acceptance TDD explained 323
10
■ Creating acceptance tests with Fit 364
11
■ Strategies for implementing acceptance tests 396
12
■ Adopting TDD 435
appendix A
■ Brief JUnit 4 tutorial 467
a p p e n d i x B
■ Brief JUnit 3.8 tutorial 470
appendix C
■ Brief EasyMock tutorial 473
a p p e n d i x D
■ Running tests with Ant 475
www.it-ebooks.info
ix

contents
preface xvii
acknowledgments xix
about this book xxi
about the cover illustration xxvii
PART 1 A TDD PRIMER 1
1
The big picture 3
1.1 The challenge: solving the right problem right 5
Creating poorly written code 5
■
Failing to meet
actual needs 6
1.2 Solution: being test-driven 7
High quality with TDD 8
■
Meeting needs with
acceptance TDD 10
■
What’s in it for me? 11
1.3 Build it right: TDD 14
Test-code-refactor: the heartbeat 15
■
Developing
in small increments 19
■
Keeping code healthy with
refactoring 24
■
Making sure the software

still works 28
www.it-ebooks.info
x CONTENTS
1.4 Build the right thing: acceptance TDD 31
What’s in a name? 31
■
Close collaboration 32
■
Tests as
a shared language 33
1.5 Tools for test-driven development 36
Unit-testing with xUnit 36
■
Test frameworks for acceptance
TDD 37
■
Continuous integration and builds 37
■
Code
coverage 39
1.6 Summary 41
2
Beginning TDD 43
2.1 From requirements to tests 45
Decomposing requirements 45
■
What are good tests made
of? 47
■
Working from a test list 47

■
Programming by intention 48
2.2 Choosing the first test 48
Creating a list of tests 49
■
Writing the first failing test 50
■
Making
the first test pass 54
■
Writing another test 56
2.3 Breadth-first, depth-first 58
Faking details a little longer 59
■
Squeezing out the fake stuff 60
2.4 Let’s not forget to refactor 63
Potential refactorings in test code 64
■
Removing a redundant test 65
2.5 Adding a bit of error handling 66
Expecting an exception 66
■
Refactoring toward smaller
methods 68
■
Keeping methods in balance 69
■
Expecting
details from an exception 70
2.6 Loose ends on the test list 71

Testing for performance 72
■
A looming design dead-end 73
2.7 Summary 73
3
Refactoring in small steps 75
3.1 Exploring a potential solution 76
Prototyping with spikes 77
■
Learning by writing
tests 77
■
Example spike for learning an API 78
3.2 Changing design in a controlled manner 80
Creating an alternative implementation 81
■
Switching over safely 86
www.it-ebooks.info
CONTENTS xi
3.3 Taking the new design further 90
Keeping things compatible 90
■
Making the switchover 95
3.4 Summary 98
4
Concepts and patterns for TDD 99
4.1 How to write tests and make them pass 100
Test-selection strategies 101
■
Implementation

strategies 104
■
Prime guidelines for test-driving 106
4.2 Essential testing concepts 108
Fixtures are the context for tests 108
■
Test doubles stand in for
dependencies 110
■
State and interaction-based testing 110
4.3 Closer look into test doubles 113
Example of a test double 113
■
Stubs, fakes, and
mocks 115
■
Mock objects in action 116
4.4 Guidelines for testable designs 118
Choose composition over inheritance 119
■
Avoid static and
the Singleton 120
■
Isolate dependencies 122
■
Inject
dependencies 124
4.5 Unit-testing patterns 127
Assertion patterns 128
■

Fixture patterns 132
■
Test patterns 137
4.6 Working with legacy code 144
Test-driven legacy development 145
■
Analyzing the
change 146
■
Preparing for the change 147
■
Test-driving
the change 148
4.7 Summary 148
PART 2APPLYING TDD TO SPECIFIC TECHNOLOGIES 151
5
Test-driving web components 153
5.1 MVC in web applications in 60 seconds 154
5.2 Taming the controller 156
Test-driving Java Servlets 156
■
Test-driving Spring
controllers 168
www.it-ebooks.info
xii CONTENTS
5.3 Creating the view test-first 173
Test-driving JSPs with JspTest 174
■
Test-driving
Velocity templates 179

5.4 TDD with component-based web frameworks 184
Anatomy of a typical framework 185
■
Fleshing out Wicket
pages test-first 186
5.5 Summary 193
6
Test-driving data access 195
6.1 Exploring the problem domain 196
Data access crosses boundaries 197
■
Separating layers with
the DAO pattern 198
6.2 Driving data access with unit tests 199
Witnessing the tyranny of the JDBC API 200
■
Reducing pain
with Spring’s JdbcTemplate 205
■
Closer to test-driven nirvana
with Hibernate 211
6.3 Writing integration tests before the code 219
What is an integration test? 220
■
Selecting
the database 222
6.4 Integration tests in action 225
Writing our first Hibernate integration test 226
■
Creating

the database schema 230
■
Implementing the
production code 233
■
Staying clean with
transactional fixtures 234
6.5 Populating data for integration tests 235
Populating objects with Hibernate 236
■
Populating data
with DbUnit 237
6.6 Should I drive with unit or integration tests? 243
TDD cycle with integration tests 243
■
Best of both
worlds 244
6.7 File-system access 245
A tale from the trenches 245
■
Practices for testable
file access 246
6.8 Summary 247
www.it-ebooks.info
CONTENTS xiii
7
Test-driving the unpredictable 249
7.1 Test-driving time-based functionality 250
Example: logs and timestamps 250
■

Abstracting
system time 252
■
Testing log output with faked
system time 256
7.2 Test-driving multithreaded code 259
What are we testing for? 260
■
Thread-safety 261
Blocking operations 266
■
Starting and
stopping threads 268
■
Asynchronous
execution 271
■
Synchronization
between threads 274
7.3 Standard synchronization objects 275
Semaphores 275
■
Latches 276
■
Barriers 276
Futures 277
7.4 Summary 277
8
Test-driving Swing 279
8.1 What to test in a Swing UI 280

Internal plumbing and utilities 281
■
Rendering and
layout 281
■
Interaction 282
8.2 Patterns for testable UI code 283
Classic Model-View-Presenter 284
■
Supervising
Controller 284
■
Passive View 287
8.3 Tools for testing view components 290
Why do we need tools? 290
■
TDD-friendly
tools 292
8.4 Test-driving a view component 297
Laying out the design 298
■
Adding and operating
standard widgets 300
■
Drawing custom
graphics 304
■
Associating gestures
with coordinates 314
8.5 Summary 319

www.it-ebooks.info
xiv CONTENTS
PART 3BUILDING PRODUCTS
WITH ACCEPTANCE TDD 321
9
Acceptance TDD explained 323
9.1 Introduction to user stories 325
Format of a story 325
■
Power of storytelling 325
■
Examples
of user stories 326
9.2 Acceptance tests 327
Example tests for a story 327
■
Properties of acceptance
tests 328
■
Implementing acceptance tests 333
9.3 Understanding the process 334
The acceptance TDD cycle 334
■
Acceptance TDD inside
an iteration 343
9.4 Acceptance TDD as a team activity 348
Defining the customer role 348
■
Who writes tests with the
customer? 350

■
How many testers do we need? 350
9.5 Benefits of acceptance TDD 351
Definition of “done” 351
■
Cooperative work 353
■
Trust and
commitment 354
■
Specification by example 354
■
Filling
the gap 354
9.6 What are we testing, exactly? 355
Should we test against the UI? 355
■
Should we stub parts of our
system? 357
■
Should we test business logic directly? 358
9.7 Brief overview of available tools 359
Table-based frameworks 359
■
Text-based frameworks 361
Scripting language-based frameworks 361
■
Homegrown tools 362
9.8 Summary 362
10

Creating acceptance tests with Fit 364
10.1 What’s Fit? 365
Fit for acceptance TDD 366
■
Test documents contain fixture
tables 369
■
Fixtures: combinations of tables and classes 371
10.2 Three built-in fixtures 372
ColumnFixture 373
■
RowFixture 376
■
ActionFixture 379E
xtending the built-in fixtures 382
www.it-ebooks.info
CONTENTS xv
10.3 Beyond the built-ins with FitLibrary 384
DoFixture 384
■
SetUpFixture 388
■
There’s more 390
10.4 Executing Fit tests 390
Using a single test document 391
■
Placing all tests in a folder
structure 391
■
Testing as part of an automated build 392

10.5 Summary 394
11
Strategies for implementing acceptance tests 396
11.1 What should acceptance tests test? 397
Focus on what’s essential 398
■
Avoid turbulent
interfaces 399
■
Cross the fence where it is lowest 400
11.2 Implementation approaches 401
Going end-to-end 401
■
Crawling under the
skin 404
■
Exercising the internals 407
■
Stubbing out
the irrelevant 409
■
Testing backdoors 411
11.3 Technology-specific considerations 411
Programming libraries 412
■
Faceless, distributed
systems 413
■
Console applications 415
■

GUI
applications 417
■
Web applications 421
11.4 Tips for common problems 425
Accelerating test execution 426
■
Reducing complexity of
test cases 431
■
Managing test data 432
11.5 Summary 434
12
Adopting TDD 435
12.1 What it takes to adopt TDD 436
Getting it 436
■
Sense of urgency 437
■
Sense of
achievement 438
■
Exhibiting integrity 438
■
Time
for change 439
12.2 Getting others aboard 440
Roles and ability to lead change 441
■
Change takes time 443

12.3 How to fight resistance 444
Recognizing resistance 444
■
Three standard responses to
resistance 448
■
Techniques for overcoming
resistance 449
■
Picking our battles 453
www.it-ebooks.info
xvi CONTENTS
12.4 How to facilitate adoption 454
Evangelize 454
■
Lower the bar 457
■
Train and
educate 458
■
Share and infect 459
■
Coach and
facilitate 461
■
Involve others by giving them
roles 463
■
Destabilize 464
■

Delayed rewards 465
12.5 Summary 465
appendix A Brief JUnit 4 tutorial 467
appendix B Brief JUnit 3.8 tutorial 470
appendix C Brief EasyMock tutorial 473
appendix D Running tests with Ant 475
resources 481
index 487





















www.it-ebooks.info

xvii
preface
Seven years ago, in the midst of a global IT boom, programming shops of all
shapes and sizes were racing like mad toward the next
IPO, and the job market
was hotter than ever. I had been pulled into the booming new media industry and
was just starting my programming career, spending long days and nights hacking
away at random pieces of code, configuring servers, uploading
PHP scripts to a
live production system, and generally acting like I knew my stuff.
On a rainy September evening, working late again, my heart suddenly skipped
a beat: What did I just do? Did I drop all the data from the production database?
That’s what it looked like, and I was going to get canned. How could I get the data
back? I had thought it was the test database. This couldn’t be happening to me!
But it was.
I didn’t get fired the next morning, largely because it turned out the customer
didn’t care about the data I’d squashed. And it seemed everyone else was doing
the same thing—it could have been any one of us, they said. I had learned a les-
son, however, and that evening marked the beginning of my journey toward a
more responsible, reliable way of developing software.
A couple of years later, I was working for a large multinational consulting com-
pany, developing applications and backend systems for other large corporations.
I’d learned a lot during my short career, thanks to all those late nights at the com-
puter, and working on these kinds of systems was a good chance to sharpen my
skills in practice. Again, I thought I knew my stuff well when I joined the ranks.
www.it-ebooks.info
xviii PREFACE
And again, it turned out I didn’t know as much as I thought. I continued to learn
something important almost every day.
The most important discovery I made changed the way I thought about soft-

ware development: Extreme Programming (
XP) gave me a new perspective on the
right way to develop software. What I saw in
XP was a combination of the high pro-
ductivity of my past hack-a-thons and a systematic, disciplined way to work. In
addition to the fact that
XP projects bring the development team closer to the cus-
tomer, the single biggest idea that struck a chord with me was test-driven develop-
ment (
TDD). The simple idea of writing tests before the code demolished my
concept of programming and unit-testing as separate activities.

TDD wasn’t a walk in the park. Every now and then, I’d decide to write tests
first. For a while, it would work; but after half an hour I’d find myself editing pro-
duction code without a failing test. Over time, my ability to stick with the test-first
programming improved, and I was able to go a whole day without falling back on
my old habits. But then I stumbled across a piece of code that didn’t bend enough
to my skills. I was coming to grips with how it should be done but didn’t yet have
all the tricks up my sleeve. I didn’t know how to do it the smart way, and fre-
quently I wasn’t determined enough to do it the hard way. It took several years to
master all the tricks, learn all the tools, and get where I am now.
I wrote this book so you don’t have to crawl over the same obstacles I did; you
can use the book to guide your way more easily through these lessons. For me,
catching the test-first bug has been the single most important influence on how I
approach my work and see programming—just as getting into agile methods
changed the way I think about software development.
I hope you’ll catch the bug, too.
www.it-ebooks.info
xix
acknowledgments

Taking an idea and turning it into a book is no small feat, and I couldn’t have
done it without the help of the legion of hard-core professionals and kind souls
who contributed their time and effort to this project.
First, thanks to Mike Curwen from JavaRanch, who started it all by connecting
me with Jackie Carter at Manning in early 2005. Jackie became my first develop-
ment editor; she taught me how to write and encouraged me to keep going. Look-
ing back at my first drafts, Jackie, I can see that what you did was a heroic act!
I’d also like to thank the rest of the team at Manning, especially publisher Mar-
jan Bace, my second development editor Cynthia Kane, technical editor Ernest
Friedman-Hill, review editor Karen Tegtmeyer, copy editor Laura Merrill, proof-
reader Tiffany Taylor, and project editor Mary Piergies. It was a true pleasure
working with all of you.
I didn’t write this book behind closed doors. I had the pleasure of getting valu-
able feedback early on and throughout the development process from an excel-
lent cast of reviewers, including J. B. Rainsberger, Ron Jeffries, Laurent Bossavit,
Dave Nicolette, Michael Feathers, Christopher Haupt, Johannes Link, Duncan
Pierce, Simon Baker, Sam Newman, David Saff, Boris Gloger, Cédric Beust, Nat
Pryce, Derek Lakin, Bill Fly, Stuart Caborn, Pekka Enberg, Hannu Terävä, Jukka
Lindström, Jason Rogers, Dave Corun, Doug Warren, Mark Monster, Jon Skeet,
Ilja Preuss, William Wake, and Bas Vodde. Your feedback not only made this a bet-
ter book but also gave me confidence and encouragement.
www.it-ebooks.info
xx ACKNOWLEDGMENTS
My gratitude also goes to the MEAP readers of the early manuscript for their
valuable feedback and comments. You did a great job pointing out remaining dis-
crepancies and suggesting improvements, picking up where the reviewers left off.
I wouldn’t be writing this today if not for my past and present colleagues, from
whom I’ve learned this trade. I owe a lot to Allan Halme and Joonas Lyytinen for
showing me the ropes. You continue to be my mentors, even if we no longer work
together on a day-to-day basis. I’d like to thank my fellow moderators at Java-

Ranch for keeping the saloon running. I’ve learned a lot through the thousands
of conversations I’ve had at the ranch. And speaking of conversations, I’d espe-
cially like to thank Bas Vodde for all the far-out conversations we’ve had on trains
and in hotel lobbies.
Special thanks to my colleagues at Reaktor Innovations for their encourage-
ment, support, enthusiasm, and feedback. You’ve taught me a lot and continue to
amaze me with your energy and talent. It’s an honor to be working with you.
I’d also like to thank my clients: the ones I’ve worked with and the ones who
have attended my training sessions. You’ve given me the practical perspective for
my work, and I appreciate it. I wouldn’t know what I was talking about if it weren’t
for the concrete problems you gave me to solve!
My life as a software developer has become easier every year due to the tools
that open source developers around the world are creating free of charge for all
of us. Parts 2 and 3 of this book are full of things that wouldn’t be possible without
your philanthropic efforts. Thank you, and keep up the good work. I hope to
return the favor one day.
Finally, I’d like to thank my family and loved ones, who have endured this
project with me. I appreciate your patience and unfailing support—even when I
haven’t been there for you as much as I should have. And, most important, I love
you guys!
www.it-ebooks.info
xxi
about this book
Test-driven development was born in the hands and minds of software developers
looking for a way to develop software better and faster. This book was written by
one such software developer who wishes to make learning
TDD easier. Because
most of the problems encountered by developers new to
TDD relate to overcom-
ing technical hindrances, we’ve taken an extremely hands-on approach. Not only

do we explain
TDD through an extended hands-on example, but we also devote
several chapters to showing you how to write unit tests for technology that’s gener-
ally considered difficult to test. First-hand experiences will be the biggest learning
opportunities you’ll encounter, but this book can act as the catalyst that gets you
past the steepest learning curve.
Audience
This book is aimed at Java programmers of all experience levels who are looking
to improve their productivity and the quality of the code they develop. Test-driven
development lets you unleash your potential by offering a solid framework for
building software reliably in small increments. Regardless of whether you’re creat-
ing a missile-control system or putting together the next YouTube, you can benefit
from adopting
TDD.
Our second intended audience includes Java programmers who aren’t neces-
sarily interested in
TDD but who are looking for help in putting their code under
test. Test-driven development is primarily a design and development technique; but
www.it-ebooks.info
xxii ABOUT THIS BOOK
writing unit tests is such an essential activity in TDD that this book will lend you a
hand during pure test-writing, too—we cover a lot of (so-called) difficult-to-test tech-
nologies such as data-access code, concurrent programs, and user-interface code.
Whether you’re simply looking to get the job done or have a larger goal of per-
sonal improvement in mind, we hope you’ll find this book helpful.
Roadmap
You’re reading a book that covers a lot of ground. In order to structure the mate-
rial, we’ve divided the book into three parts with distinct focuses. Part 1 intro-
duces the book’s main topics—test-driven development and acceptance test-
driven development—starting with the very basics.

Chapter 1 begins with a problem statement—the challenges we need to over-
come—and explains how
TDD and acceptance TDD provide an effective solution
in the form of test-first programming, evolutionary design, test automation, and
merciless refactoring.
Chapter 2 gets our hands dirty, extending our understanding of
TDD through
an in-depth example: a homegrown template engine we test-drive from scratch.
Along the way, we discuss how to manage the tests we want to write in a test list
and how to select the next test from that list.
Chapter 3 finishes what chapter 2 started, continuing the development of the
template engine through an extensive design change, starting with a spike—a
learning experiment—and then proceeding to make the change to the template
engine in a controlled, disciplined manner.
Chapter 4 brings our perspective back to a higher level to explain the strate-
gies in our toolkit, from selecting tests to making them pass. We also talk about
essential testing concepts such as fixtures, test doubles, and the differences
between state- and interaction-based testing. After giving some guidelines for cre-
ating testable designs, chapter 4 ends with an overview of a number of key test pat-
terns and a section on working in a test-first manner with legacy code.
Part 2 is about getting dirty again, demonstrating through working examples
how we can apply
TDD when working with a variety of technologies that are some-
times referred to as being “difficult to test-drive.” After part 2, you’ll know that
folks who say that don’t know what they’re talking about!
Chapter 5 starts our journey through the trenches of web development. We
learn to test-drive request/response-style web layers using plain old Java Servlets
and Spring Controllers, and we learn to test-drive the presentation layer built with
JavaServer Pages and Apache Velocity templates. The chapter also contrasts these
request/response examples with test-driving web applications using a component-

based framework, Apache Wicket.
www.it-ebooks.info
ABOUT THIS BOOK xxiii
Chapter 6 explains how to test-drive the data-access layer behind our web com-
ponents. We’ll see examples of test-driving data-access objects based on raw
JDBC
code, the Spring Framework’s JdbcTemplate API, and the de facto object-relational
mapping (
ORM) tool, Hibernate. We’ll also discuss how to deal with the database
in our unit tests and how to fill in the gaps with integration tests. Finally, we share
a few tricks for dealing with the file system.
Chapter 7 takes us to the land of the unknown: nondeterministic behavior.
After first examining our options for faking time, we turn our attention to multi-
threading. We begin with a discussion of what we can and should test for, explor-
ing topics such as thread safety, blocking operations, starting and stopping
threads, and asynchronous execution. Our trip to the world of the unpredictable
ends with a tour of the new synchronization objects from
java.util.concurrent
that were introduced in Java 5.
Chapter 8 is about face—the face of Java Swing applications, that is. Again, we
begin by figuring out what we should test for when test-driving
UI code. Then, we
look at three design patterns that make our test-driven lives easier, and we briefly
introduce two open source tools—Jemmy and Abbot—for unit-testing Swing com-
ponents. We finish chapter 8 (and part 2) with an extended example, test-driving
the face and behavior for a custom Swing component.
Part 3 is a change of tempo. We move from the concrete world of test-driving
objects and classes into the fuzzier world of building whole systems in a test-first
manner with acceptance
TDD.

Chapter 9 gets us going with an introduction to user stories for managing
requirements, and to the essence of acceptance tests. Once we’re up to speed with
the what, we focus on the how—the process of acceptance
TDD and what it
requires from the team. We also crystallize the benefits of and the reasons for
developing software with acceptance
TDD. The chapter ends with a discussion of
what kinds of aspects our acceptance tests should specify about the system we’re
building and an overview of some of the tools in our disposal.
Chapter 10 makes acceptance
TDD more concrete by taking a closer look at Fit,
a popular acceptance-testing tool. Our Fit tutorial begins with a description of how
the developer can use Fit to collaborate with the customer, first sketching accep-
tance tests in a tabular format and then touching them up into syntax recognized
by Fit. We then see how to implement the backing code that glues our tabular tests
into interaction with the system, first going through the three standard fixtures
built into Fit and then looking at additional utilities provided by the FitLibrary, an
www.it-ebooks.info
xxiv ABOUT THIS BOOK
extension to Fit. Finally, we learn to run our precious Fit tests from the command
line and as part of an Apache Ant build.
Chapter 11 expands our perspective by looking at a number of strategies for
implementing our acceptance tests independent of the tools in use. After going
through our options for connecting tests to the system we’re developing, we dis-
cuss the kinds of limitations and opportunities that technology puts in our way.
We also share some tips for speeding up acceptance tests and keeping complexity
in check.
Chapter 12 ends part 3 as a black sheep of sorts—a chapter on ensuring the
success of
TDD adoption. We begin by exploring what ingredients should be in

place for us to achieve lasting change, both for ourselves and for our peers. We
then focus on resistance: how to recognize it and how to deal with it. Finally, we go
through a long list of things in our toolbox that can facilitate the successful adop-
tion we’re seeking.
Because writing unit tests is so central to test-driven development, we’ve also
provided three brief tutorials on some of the essential tools; you can use them as
cheat sheets. Appendices A and B are for the
JUnit unit-testing framework, illus-
trating the syntax for versions 4.3 and 3.8, respectively. Appendix C does the same
for EasyMock, a dynamic mock-object framework we can use to generate smart
test doubles.
Test-driving code in the comfort of our favorite
IDE is cool, but we need to
make those tests part of our automated build. That’s why we’ve included appen-
dix D: a brief tutorial for running JUnit tests with Apache Ant, the standard build
tool for Java developers.
Code conventions
The code examples presented in this book consist of Java source code as well as a
host of markup languages and output listings. We present the longer pieces of
code as listings with their own headers. Smaller bits of code are run inline with
the text. In all cases, we present the code using a
monospaced
font, to differentiate
it from the rest of the text. In part 2, we frequently refer from the text to elements
in code listings. Such references are also presented using a
monospaced
font, to
make them stand out from plain English. Many longer listings also have num-
bered annotations that we refer to in the text.
Code downloads

The complete example code for the book can be downloaded from the Manning
website page for this book, at This includes
www.it-ebooks.info