This document discusses test-driven development for an auction sniping bot. It describes writing tests to check that the bot receives price updates from a fake auction, bids incrementally in response, and updates the user interface on auction close. New classes like AuctionMessageTranslator are extracted to separate concerns and close the loop between auction events and UI updates. The document emphasizes starting with external triggers and tests to drive the development process inward through small method extractions.

1. Chapter 12. Getting
Ready to Bid
Yenifer Barco Castrllón

2. An introduction to the Market

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.

4. A Test for Bidding

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

9. The AuctionMessageTranslator

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.

12. Finish the Job

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