From the author of

From the author of

Getting the Test to Pass

In order to get the test to pass, we first need to store a reference to the
Deal button in a field. We also want to rename it from the generic name
button to dealButton, a name that makes more sense in the
larger context of the class. Once we get those changes to pass, we can add the
method addDealListener. Its implementation is simple—all it does
is delegate to the JButton method addActionListener. Listing 2 shows
the complete set of code changes to TablePanel.

We’ve proven that our view supports pluggable actions, but we
haven’t defined yet what the correct action is for our Texas Hold
’Em application. We’ll need code that tells the view to start
dealing cards when the user clicks the Deal button. This code will be part of an
application class.

Before proceeding, I notice that the HoldEm class is inappropriately
named. It’s really a view component, even though it has the ability to be
executed as an application from the command line. Let’s rename it to
HoldEmFrame, and rename the test to HoldEmFrameTest. Looking
at HoldEmFrameTest, we should also rename the HoldEmFrame
instance variable app:

We’d rather use the simple field name frame, but that’s
already taken. There’s probably a better pair of names, but the important
thing is that we improved upon a poor name. We can always revisit the name next
time we have to touch the code.

Let’s start by building a simple test that creates an application
class. Listing 3 shows the test, and Listing 4 shows the application class
HoldEmApp.

Listing 4 Initial implementation of the application.

The primary goal of testRun is to verify that the actual frame is
displayed when we run the application. I don’t like having to obtain a
HoldEmFrame object so that we can ask for its underlying JFrame. We
have two options:

Change HoldEmFrame so that it’s a JFrame.

Fake the show method on HoldEmFrame and verify that it
gets called.

Neither of these options is perfect; technically, both testing forms break
encapsulation. For now, we’ll choose the non-mock solution. It seems
simpler to just execute code and see what effects propagate. We’ll use
this as a guiding principle going forward, although I’m sure that
we’ll have to resort to mocking at some point.

We can drive the design change through the unit test. Step 1, we insist that
HoldEmFrame is a JFrame: