3. • Single item: join, bid,
and lose. When a price
comes in, send a bid
raisedby the minimum
increment defined by
the auction. This
amount will be
included in the price
update information.
• Single item: join, bid,
and win. Distinguish
which bidder is
currently winning the
auction and don’t bid
against ourselves.
5. Starting with a Test
So we decide that the next
one will add some price
information. The steps are:
1. Tell the auction to send a
price to the Sniper.
2. Check the Sniper has
received and responded to the
price.
3. Check the auction has
received an incremented bid
from Sniper.
6. Extending the Fake
Auction
We have two methods to
write in the FakeAuctionServer
to support the end to-end
test:
• reportPrice() has to send a
Price message through the
chat.
• hasReceivedBid() is a little
more complex—it has to
check that the auction
received the right values from
the Sniper.
7. Outside-In Development
Test-driven development is
to start with the outside
event that triggers the
behavior we want to
implement and work our
way into the code an object
at a time, until we reach a
visible effect (such as a sent
message or log entry)
indicating that we’ve
achieved our goal.
8. Infinite Attention to Detail?
How can we hope to
catch all the
configuration options
in an entire system?
At some level we can’t,
and this is at the heart of
what professional testers
do.
What we can do is push
to exercise as much as
possible of the system as
early as possible, and to
do so repeatedly
10. Teasing Out
a New Class
Our entry point to the
Sniper is where we receive
a message from the
auctionthrough the Smack
library: it’s the event that
triggers the next round of
behavior we want to make
work.
In practice, this means that
we need a class
implementing
MessageListener to attach
to the Chat.
When this class receives a raw message from the auction, it
will translate it into something that represents an auction event
within our code which, eventually, will prompt a Sniper action
and a change in the user interface.
11. Closing the
User
Interface
Loop
Previously, Main updated
the Sniper user interface,
so now we make it
implement
AuctionEventListener and
move the functionality to
the new auctionClosed()
method.
13. We write a high-
level end-to-end test
to describe what the
Sniper should
implement.
1
we write long unit
test names to tell us
what a class does.
2
we extract new
classes to tease
apart fine-grained
aspects of the
functionality.
3
we write lots of little
methods to keep
each layer of code at
a consistent level of
abstraction.
4
Editor's Notes
Each acceptance test we write should have just enough new requirements to force a manageable increase in functionality
We also pull up the Matcher clause from the SingleMessageListener to give the FakeAuctionServer more flexibility in defining what it will accept as a message.
We can also help ourselves cope with total system complexity by keeping the quality of its components high and by constantly pushing to simplify.
We can also help ourselves cope with total system complexity by keeping the quality of its components high and by constantly pushing to simplify.
When this class receives a raw message from the auction, it will translate it into something that represents an auction event within our code which, eventually, will prompt a Sniper action and a change in the user interface.
