Anthony's Software Blog

TDDing a Card Game part 6

2006-04-07T09:05:00.000-07:00

Last time we dealt with how Player notifies game that it's stuck. I also expressed some concern that I haven't extracted the game class. This time we'll start with one more test for player then we'll look at extracting the game class from SpitPlayerRules. Along the way we'll see the Single Responsibility Principle.

One Last Player Tweak For Now

In the game of Spit there are two piles on which the players spit. Adding the second pile is the last little tweak I want to make to Player before I extract a game. I'll write a test to force the Player to spit on a second pile.

class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @player = Player.new(self)
    #Game double's state
    @pile_one = SpitPile.new(7)
    @stock = []
    @spit_reserve = []
  end

  def test_player_can_play_on_either_pile
    @pile_two = SpitPile.new(5)
    @player.hand = [ 2, 3, 2, 3, 4 ]
    @player.play
    assert_equal [7] , @pile_one.to_a
    assert_equal [5, 4, 3, 2, 3, 2], @pile_two.to_a
  end

Notice that no card in @player.hand can be played on @pile_one. That will force the player to spit on @pile_two. We should run the test to make sure it fails... It does. Looking at the current Player code it's pretty clear that we need to change the bold line below

class Player
  def spit
    card_to_play = @hand.pop 
    unless @game.spit_on_one(card_to_play)
      @invalid_moves += 1
      @hand.unshift(card_to_play)
    end
    if @invalid_moves == 5
      @game.stuck
      @invalid_moves = 0
    end
  end
end

to this

unless @game.spit_on_one(card_to_play) or @game.spit_on_two(card_to_play)

Of course we're assuming that @game responds to #spit_on_two. Let's make it so. Remember that @game is still just an instance of SpitPlayerRules

class SpitPlayerRules < Test::Unit::TestCase
  # game methods
  def spit_on_two( card )
    @pile_two.play card
  end
end

Now we'll run the tests and move on...

D'oh. We have two failing tests: #test_player_draws_when_hand_is_short and #test_when_stuck_player_asks_for_new_spit. Can you spot why? Hmm, maybe the error message will help. It's the same for both failures.

NoMethodError: undefined method `play' for nil:NilClass
    SpitTest.rb:70:in `spit_on_two'
    ./spit.rb:48:in `spit'
    ./spit.rb:38:in `play'
    SpitTest.rb:48:in `test_player_draws_when_hand_is_short'

Ah ha! Player is trying to #spit_on_two, but @pile_two is nil in all but the test we just wrote. So I'll add it to the setup and initialize it with something that isn't playable.

class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @player = Player.new(self)
    #Game double's state
    @pile_one = SpitPile.new(7)
    @pile_two = SpitPile.new(0)
    @stock = []
    @spit_reserve = []
  end
end

We're on a green bar so let's refactor. I notice that the logic in Player#spit is rather crufty and obtuse. Let's see if you agree.

class Player
  def spit
    card_to_play = @hand.pop 
    unless @game.spit_on_one(card_to_play) or @game.spit_on_two(card_to_play)
      @invalid_moves += 1
      @hand.unshift(card_to_play)
    end
    if @invalid_moves == 5
      @game.stuck
      @invalid_moves = 0
    end
  end
end

It looks like in this method Player spits a card then assess the situation. The Single Responsibility Principle (SRP) says that a class should have one and only one reason to change. I like to extend this down to the method level as well. In this case I think we should split this method in two. First I'll extract each conditional into it's own method. The tests still pass. Player#spit isn't pulling it's own weight, so I'm going to inline it. Test are still passing. I'll reorder the statements in the while loop of Player#play and then I'll show the code. Okay, the tests are passing and here's the code.

class Player
  def play
    while(!@hand.empty?)
      assess_situation
      draw
      spit_card
    end
  end
  def spit_card 
    card_to_play = @hand.pop 
    unless @game.spit_on_one(card_to_play) or @game.spit_on_two(card_to_play)
      @invalid_moves += 1
      @hand.unshift(card_to_play)
    end
  end
  def assess_situation
    if @invalid_moves == 5
      @game.stuck
      @invalid_moves = 0
    end
  end
end

Smashing SpitPlayerRules with SRP

Speaking of SRP, we have a big issue with SRP in the SpitPlayerRules class. Right now SpitPlayerRules is both the test fixture and the game double. This is a clear violation of the principle. We've been aware of it for some time now. In fact it was a conscious decision to leave it alone, until now. We're going to extract the Game class from SpitPlayerRules. We're going to do this in very small steps and always keep the tests green because that's what the TDD people say to do. First I'll show the entire SpitPlayerRules, then I'll discuss each step and show the affected portions of the code.

class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @player = Player.new(self)
    #Game double's state
    @pile_one = SpitPile.new(7)
    @pile_two = SpitPile.new(0)
    @stock = []
    @spit_reserve = []
  end
  def test_run_without_draw
    @player.hand = [ 2, 3, 4, 5, 6 ]
    @player.play
    assert_equal [7, 6, 5, 4, 3, 2] , @pile_one.to_a
  end
  def test_player_draws_when_hand_is_short
    @stock << 2
    @player.hand = [3, 4, 5, 6]
    @player.play
    assert @stock.empty?, "player did not draw as expected"
  end
  def test_when_stuck_player_asks_for_new_spit
    @spit_reserve  << 3 << 6
    @player.hand = [2, 2, 3, 4, 5]
    @player.play
    assert @spit_reserve.empty?, "player did not ask for a new spit"
  end
  def test_player_can_play_on_either_pile
    @pile_two = SpitPile.new(5)
    @player.hand = [ 2, 3, 2, 3, 4 ]
    @player.play
    assert_equal [7] , @pile_one.to_a
    assert_equal [5, 4, 3, 2, 3, 2], @pile_two.to_a
  end

  # game methods
  def spit_on_one( card )
    @pile_one.play card
  end
  def spit_on_two( card )
    @pile_two.play card
  end
  def draw
    @stock.pop
  end
  def draw?
    ! @stock.empty?
  end 
  def stuck
    @pile_one.new_spit(@spit_reserve.pop)
  end 
end

First we need an empty class to move all the game methods to.

class Game
end

That was easy enough. And the tests are still green. Where do we go from here? Let's pick a method and move it to the new class. Remember we can't let the tests break so we'll need to give SpitPlayerRules an instance of Game to use. Sometimes it's easier to move methods and data in clumps. Let's move #draw, #draw?, and @stock.

class Game
  attr_accessor :stock
  def draw
    @stock.pop
  end
  def draw?
    ! @stock.empty?
  end
end
class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @player = Player.new(self)
    #Game double's state
    @game = Game.new
    @game.stock = []
    @pile_one = SpitPile.new(7)
    @pile_two = SpitPile.new(0)
    @spit_reserve = []
  end
  def test_player_draws_when_hand_is_short
    @game.stock << 2
    @player.hand = [3, 4, 5, 6]
    @player.play
    assert @game.stock.empty?, "player did not draw as expected"
  end
  # game methods
  def draw
    @game.draw
  end
  def draw?
    @game.draw?
  end 
end

Yes! The tests are still green. Alright all that's left is #stuck, #spit_on_*, @pile_*, and @spit_reserve. Let's move them.

class Game
  attr_reader :stock
  attr_reader :spit_reserve
  attr_accessor :pile_one
  attr_accessor :pile_two
  def spit_on_one( card )
    @pile_one.play card
  end
  def spit_on_two( card )
    @pile_two.play card
  end
  def stuck
    @pile_one.new_spit(@spit_reserve.pop)
  end 
end
class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @player = Player.new(self)
    #Game double's state
    @game = Game.new
    @game.stock = []
    @game.pile_one = SpitPile.new(7)
    @game.pile_two = SpitPile.new(0)
    @game.spit_reserve = []
  end
  def test_run_without_draw
    @player.hand = [ 2, 3, 4, 5, 6 ]
    @player.play
    assert_equal [7, 6, 5, 4, 3, 2] , @game.pile_one.to_a
  end
  def test_when_stuck_player_asks_for_new_spit
    @game.spit_reserve  [3, 6]
    @player.hand = [2, 2, 3, 4, 5]
    @player.play
    assert @game.spit_reserve.empty?, "player did not ask for a new spit"
  end
  def test_player_can_play_on_either_pile
    @game.pile_two = SpitPile.new(5)
    @player.hand = [ 2, 3, 2, 3, 4 ]
    @player.play
    assert_equal [7] , @game.pile_one.to_a
    assert_equal [5, 4, 3, 2, 3, 2], @game.pile_two.to_a
  end
  # game methods
  def spit_on_one( card )
    @game.pile_one.play card
  end
  def spit_on_two( card )
    @game.pile_two.play card
  end
  def stuck
    @game.pile_one.new_spit(@spit_reserve.pop)
  end 
end

Green Bar! Now let's move the game setup from SpitPlayerRules#setup to Game#initialize.

class Game
  def initialize
    @stock = []
    @spit_reserve = []
    @pile_one = SpitPile.new(7)
    @pile_two = SpitPile.new(0)
  end
end

Finally, we can replace the self shunt of SpitPlayerRules with @game, and remove all the game specific methods from SpitPlayerRules.

class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @game = Game.new
    @player = Player.new(@game)
  end
end

The tests are still green. One last thing, Game#initialize is setting up for the tests, and all of the data members of Game have accessors. Maybe we should introduce a GameDouble that will setup the state and provide access to the members. It might look like this

class GameDouble < Game
  attr_reader :stock
  attr_reader :spit_reserve
  attr_accessor :pile_one
  attr_accessor :pile_two
  def initialize
    @stock = []
    @spit_reserve = []
    @pile_one = SpitPile.new(7)
    @pile_two = SpitPile.new(0)
  end
end

I rather like that, so I'll hook it into the Player rules and clean up Game accordingly.

class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @game = GameDouble.new
    @player = Player.new(@game)
  end
end

Until Next Time

Whew. That was as lot of code movement. I'll show the code in it's entirety below. Let's look at what we've done today. We've finally broken out a Game class, we introduced a test double for that game class, and we brought the Player class one step closer to done. There are a few warts. The most notable wart is the integers that represent cards. We need to do something about that next time.

Forming Riverside.rb

2006-04-05T09:26:00.000-07:00

If you're in the Riverside, California area and are into Ruby or are looking into Ruby, then you might be interested in starting the Riverside Ruby Users Group. If you're interested join the mailing list, and introduce yourself. We'll work out the when and where once we've got the who.

SD Ruby User Group

2006-03-27T06:42:00.000-08:00

Kevin Clark and many others are reviving the San Diego Ruby Users Group. I am very excited, and I plan to help out in any way I can. I won't be able to make many of the meetings though. The reason I won't is I live almost 90 miles from San Diego even though I work there. I wonder if there'd be enough interest in a Riverside/San Bernardino RUG?

TDDing a Card Game part 5

2006-03-27T06:20:00.000-08:00

In part three We started with four questions.

What happens when player makes an invalid move?
How does Player draw from its stock pile?
How does Player get notified of the end of game play?
Does player notify Game when its out of cards?

We developed how Player draws a card in that entry. One thing that has been bugging me is that we don't have an actual Game class yet. We do have most of an interface or protocol that the Game class will implement, but it is completely contained in the SpitPlayerRules TestCase. Should I extract it now? Should I have stubbed a Game class out earlier instead of using the test case as a double? Should I wait a little longer before extracting it? I think I'll wait for now because I want the interface between Player and Game to emerge a little bit more. Of course this might not be the best idea.

Bad Move

What happens when player makes an invalid move? An invalid move could be trying to draw a card when the Player already has five cards in its hand or trying to play a card out of sequence. Thinking ahead a bit and looking at the last entry, we know at some point we want to let third parties write Players, so I don't think we want Player to be responsible for enforcing the five card in the hand limit. The other invalid move is part of the interface between player and game, and is addressed by the rules of the game. Specifically, the Players will turn a new spit card when both Player's are stuck. We are, for the moment, dealing with one player, so we will focus on how a Player notifies the Game that it's stuck. Let's express that in Ruby

class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @player = Player.new(self)
    #Game double's state
    @pile_one = [7]
    @pile_two = [7]
    @stock = []
  end
  def test_when_stuck_player_asks_for_new_spit
    @spit_reserve = [6]
    @player.hand = [2, 2, 3, 4, 5]
    @player.play
    assert @spit_reserve.empty?, "player did not ask for a new spit"
  end
end

To Prefactor or Not To Prefactor

I expect that Game needs to notify Player when a move is invalid, and that will introduce duplication in the game double because it must implement the logic that is in SpitPile. There are at least two options here. One, we could press on and let the actual duplication show us what we need. Two, we could back out the failing test and replace the array, @pile_one, with a SpitPile. In this case I'm going with option two because I think the need for SpitPile is clear. Under other circumstances I might choose differently.

Looking over the current code I noticed that @pile_two is unused, so I'll remove it. Moving on to the replacement. We need to change the initialization of @pile_one in the setup and the #<< in spit_on_one. I'll show that and run the tests.

class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @player = Player.new(self)
    #Game double's state
    @pile_one = SpitPile.new(7)
    @stock = []
  end
  # game methods
  def spit_on_one( card )
    @pile_one << card
  end
  def draw
    @stock.pop
  end
  def draw?
    ! @stock.empty?
  end

D'oh! The #test_run_without_draw fails. The message points to the following

class SpitPlayerRules < Test::Unit::TestCase
  def test_run_without_draw
    @player.hand = [ 2, 3, 4, 5, 6 ]
    @player.play
    assert_equal [7, 6, 5, 4, 3, 2] , @pile_one
  end

Obviously SpitPile is not an Array, so that comparison won't work. I'll just add a test for a SpitPile#to_a method, and then implement and use it.

class SpitPileRules < Test::Unit::TestCase
  def setup
    @pile = SpitPile.new( 2 )
  end
  def test_to_a
    assert @pile.play(3)
    assert_equal [2, 3], @pile.to_a
  end
end
class SpitPile
  def initialize( first_card )
    @pile = [ first_card ]
  end
  def to_a
    @pile
  end 
end
class SpitPlayerRules < Test::Unit::TestCase
  def test_run_without_draw
    @player.hand = [ 2, 3, 4, 5, 6 ]
    @player.play
    assert_equal [7, 6, 5, 4, 3, 2] , @pile_one.to_a
  end

Passing the Test

Okay, let's restore the test for an invalid move and a stuck player and see if we can make it pass.

class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @player = Player.new(self)
    #Game double's state
    @pile_one = SpitPile.new(7)
    @stock = []
    @spit_reserve = []
  end
  def test_when_stuck_player_asks_for_new_spit
    @spit_reserve = [6]
    @player.hand = [2, 2, 3, 4, 5]
    @player.play
    assert @spit_reserve.empty?, "player did not ask for a new spit"
  end
end

I had a little trouble making that pass. Mostly because when I first wrote the test I wrote

@spit_reserve = [6]

That didn't provide the Player with enough valid moves. Changing it to

@spit_reserve = [3, 6]

solved that problem. Let's review the code that makes the test pass. It's in Player#spit, which is called from Player#play

class Player
  attr_accessor :hand
  def initialize( game )
    @game = game
  end
  def spit
    card_to_play = @hand.pop 
    unless @game.spit_on_one(card_to_play) 
      @invalid_moves += 1
      @hand.unshift(card_to_play)
    end
    if @invalid_moves == 5
      @game.stuck
      @invalid_moves = 0
    end   
  end
end

As you may notice the logic here is crufty. I think that it's okay for now because we are using this Player to explore the interaction between game and Player. I fully expect to make a few other Player class for AI and human play. This simple Player is essentially just playing cards in the order they are in @hand and counting how many @invalid_moves he gets. Then he tells the game when he's stuck. This required that I add the following to the game double and SpitPile.

class SpitPlayerRules < Test::Unit::TestCase
  # game methods
  def stuck
    @pile_one.new_spit(@spit_reserve.pop)
  end 
end
class SpitPile
  def new_spit( card )
    @pile << card
  end
end

And now the tests are all passing.

Stopping For Today

I'm still concerned about not having a game class, but I can see its shape a little more clearly now. I think one more tweak to the Player class and then I'll extract the game. I'm out of time for now, so that'll have to wait for the next entry. I might even get ambitious and get a new entry up before next week. Until then.

TDDing a Card Game - The Why and What

2006-03-04T23:45:00.000-08:00

I've noticed, while reading the previous three entries, I haven't made very clear my plan. I've described the game, and jumped right into the code. I haven't given a clear direction for this project. Also, I haven't explained why I'm writing this. So I'm going to spend this post explaining the Why and the What of this series.

First, the Why

I was first introduced to TDD over two years ago. Since that time I have regularly tried to apply it in the work that I do, but often the code base and time constraints conspire against my efforts to work in a completely test driven fashion. While I am often impressed by the simplicity TDD helps me create, I regularly find myself stuck against something I don't know how to test. In the face of looming deadlines I often buckle and just code up a mess that kind of works for now.
Chad Fowler's book on architecting your career is the reason I started this blog. As result of that first exercise from the book, I realized that publishing could provide a good way of reflecting on why and how I do the things I do. This reflection will be a crucial part of improving my skills and abilities. I decided I needed a project to practice in a completely test driven way.

Now, the What

In the first post in this series I described the card game Spit. I then jumped right into implementing it. I kind of had in my head where I was planning to go, but it is not as clear as it could be. Since my time to devote to writing this is limited, and I am often absent minded, I need to write down a high level path that will help me resume when I need too.
The first three entries in this series are headed towards a player versus AI on the command line type game. One of the primary goals for me in writing this program is to stretch my ability in places where I think TDD will be hard. With that in mind, I want a full GUI player versus AI mode to help explore the difficulties I imagine for test driving GUIs. A player API to allow custom AI players would be neat. Player versus player mode would expose some of the perceived difficulty in testing network interactions. A web application for player versus player mode right in a browser would allow me to explore Ruby on Rails.
Whew! Did I leave out anything? I know all that is extremely ambitious. In fact, it seems a lot like that first meeting with a customer when they have a great new idea. Well good. Sometimes I think I will put a customer hat on and review the work I've done and strategize about the next steps. For now I'll put the hat away and in the next entry I'll work towards the command line version of the game.

TDDing a Card Game part 3

2006-02-22T10:32:00.000-08:00

Last week I ended with the following questions

What happens when player makes an invalid move?
How does Player draw from its stock pile?
How does Player get notified of the end of game play?
Does player notify Game when its out of cards?

Today I'll pick start by picking a question and translating it into a test. I'll focus on the stock pile question.

#SpitPlayerRules
def test_player_draws_when_hand_is_short
  @stock = [2]
  player = Player.new(self)
  player.hand = [3, 4, 5, 6]
  @pile_one = [7]
  @pile_two = [7]
  player.play
  assert @stock.empty?, "player did not draw as expected"
end

Remember that SpitPlayerRules is using the self shunt pattern so it is a double (think stunt double) for the still theoretical Game object. I've primed the Player under test with a hand that is one card short. Also I've assumed that somehow that Player will be able to draw from the @stock that the test/Game double has. In our implementation we need to consider how the Game communicates to the Player that the stock pile is empty. I ran that and it failed predictably.

Here is the old Player#play

def play
  while(!@hand.empty?)
    @game.spit_on_one(@hand.pop)
  end
end

Should we draw before or after we spit? For now I'll say before, and implement the draw as quickly as I can

def play
  while(!@hand.empty?)
    if @hand.size < 5 and @game.draw?
      @hand << @game.draw 
    end
    @game.spit_on_one(@hand.pop)
  end
end

Before this can run we need to implement the two methods draw and draw? on our Game double.

#SpitPlayerRules
def draw
  @stock.pop
end
def draw?
  ! @stock.empty?
end

I'll just run the test and ... D'oh I need to make @stock an empty array in #test_run_without_draw to make it pass. Good that was fairly easy. Now on to the text test.

Wait! The TDD mantra is red (check), green (check), REFACTOR. Okay is there anything we can do to make the code simpler? What is Simple Code? There are several formulations of guidelines for simplicity in code here. The first guideline is "runs all tests", and we are good there. The next is "contains no duplication". While the Player class is acceptable. Its tests are not. The duplication is the set up the of the Player under test and the Game double's state. I'll factor that out into setup method.

#SpitPlayerRules 
def setup 
  @player = Player.new(self)
  #Game double's state
  @pile_one = [7]
  @pile_two = [7]
  @stock = []
end
def test_run_without_draw
  @player.hand = [ 2, 3, 4, 5, 6 ]
  @player.play
  assert_equal [7, 6, 5, 4, 3, 2] , @pile_one
end
def test_player_draws_when_hand_is_short
  @stock << 2
  @player.hand = [3, 4, 5, 6]
  @player.play
  assert @stock.empty?, "player did not draw as expected"
end

The third guideline is "expresses all the ideas you want to express". Looking at Player#play I think there are two ideas that are contained in that one method: draw and spit. I'll extract a method for each concept.

#Player
def play
  while(!@hand.empty?)
    draw
    spit
  end
end
def draw
  if @hand.size < 5 and @game.draw?
    @hand << @game.draw 
  end    
end
def spit
  @game.spit_on_one(@hand.pop)    
end

The final guideline "minimizes classes and methods". It makes me think twice about the decision to extract #spit. I'm a little uncertain if the #spit method is pulling its weight. On the one hand it is only one line long. On the other hand it makes explicit the action in the card game and provides a place for any more advanced decision making at that point in the game. I think I'll keep it for now.

I'm going to stop here because I'm trying to spend only an hour on this entry. I think we've made some progress here. The interaction between Player and Game is starting to show up in the SpitPlayerRules class. We covered some guidelines for simple code and applied them. And we answered one of the questions we asked last week. So until next time I'll leave you with a listing of the current state of things.

#--------------Spit.rb
class SpitPile
  def initialize( first_card )
    @pile = [ first_card ]
  end
  def play( card )
    if in_sequence?(card)
      @pile << card
      return true
    end
    false
  end
  def to_s 
    @pile.join(', ')
  end
  def top_card
    @pile.last
  end
  def in_sequence?( card )
    (card - top_card).abs == 1
  end
end

class Player
  attr_accessor :hand
  def initialize( game )
    @game = game
  end
  def play
    while(!@hand.empty?)
      draw
      spit
    end
  end
  def draw
    if @hand.size < 5 and @game.draw?
      @hand << @game.draw 
    end    
  end
  def spit
    @game.spit_on_one(@hand.pop)    
  end
end
#----------------SpitTest.rb
require 'test/unit'
require 'spit'

class SpitPileRules < Test::Unit::TestCase
  def setup
    @pile = SpitPile.new( 2 )
  end
  def test_accepts_card_of_next_higher_rank
    assert @pile.play(3)
    assert_equal "2, 3", @pile.to_s
  end
  def test_accepts_card_of_next_lower_rank
    assert @pile.play(1)
    assert_equal "2, 1", @pile.to_s
  end
  def test_rejects_card_of_same_rank
    assert !@pile.play(2)
    assert_equal "2", @pile.to_s
  end
  def test_rejects_cards_of_non_consecutive_rank
    assert @pile.play(3)
    assert !@pile.play(1)
    assert_equal "2, 3", @pile.to_s
  end
end

class SpitPlayerRules < Test::Unit::TestCase
  def setup 
    @player = Player.new(self)
    #Game double's state
    @pile_one = [7]
    @pile_two = [7]
    @stock = []
  end
  def test_run_without_draw
    @player.hand = [ 2, 3, 4, 5, 6 ]
    @player.play
    assert_equal [7, 6, 5, 4, 3, 2] , @pile_one
  end
  def test_player_draws_when_hand_is_short
    @stock << 2
    @player.hand = [3, 4, 5, 6]
    @player.play
    assert @stock.empty?, "player did not draw as expected"
  end

  # game methods
  def spit_on_one( card )
    @pile_one << card
  end
  def draw
    @stock.pop
  end
  def draw?
    ! @stock.empty?
  end 
end

TDDing a Card Game part 2

2006-02-15T08:34:00.000-08:00

In the last entry I wrote a pretty simple class, SpitPile. It is responsible for enforcing the rules for playing a card in the card game Spit.

I received some feedback from Jim Hughes via the TDD yahoogroup. Jim kindly pointed out a corollary to the TDD rule "Only write code to pass a failing test". His corollary is "Always delete production code when it won't break a test". Then he suggested a place in the SpitPile where I could apply this corollary. In SpitPile#in_sequence? I have this

def in_sequence?(card) 
  (card != top_card) and ((card - top_card).abs == 1)
end

What I noticed, with Jim's guidance, is the logical duplication in that snippet. So I removed it and the tests still passed. Mmm, feel that green bar goodness.

Here is the code for SpitPile in its entirety

class SpitPile
  def initialize( first_card )
    @pile = [ first_card ]
  end
  def play( card )
    if in_sequence?(card)
      @pile << card
      return true
    end
    false
  end
  def to_s
    @pile.join(', ')
  end
  def top_card
    @pile.last
  end

  def in_sequence?( card )
    (card - top_card).abs == 1
  end

end

and the tests

class SpitPileRules < Test::Unit::TestCase
  def setup
    @pile = SpitPile.new( 2 )
  end
  def test_accepts_card_of_next_higher_rank
    assert @pile.play(3)
    assert_equal "2, 3", @pile.to_s
  end
  def test_accepts_card_of_next_lower_rank
    assert @pile.play(1)
    assert_equal "2, 1", @pile.to_s
  end
  def test_rejects_card_of_same_rank Okay I'm stuck. I can't c
    assert !@pile.play(2)
    assert_equal "2", @pile.to_s
  end
  def test_rejects_cards_of_non_consecutive_rank
    assert @pile.play(3)
    assert !@pile.play(1)
    assert_equal "2, 3", @pile.to_s
  end
end

Onward. I think I'm going to work on a Game object to manage the flow of pay. Spit is not turn based so I'm thinking I might have to do some threading magic. That is notoriously difficult to test, but I'm not sure I'll need it yet.

Start with a test. Okay, I'm stuck. I can't think of a simple test for Game without going immediately to a Player, but I did come up with this test for Player

class SpitPlayerRules < Test::Unit::TestCase
  def test_run_without_draw
    player = Player.new(self)
    player.hand = [ 2, 3, 4, 5, 6 ]
    @pile_one = [7]
    @pile_two = [7]
    player.play
    assert_equal [7, 6, 5, 4, 3, 2] , @pile_one
  end
end

This test assumes that player will modify SpitPlayerRules@pile_one which begs the question, how? This makes me think about the interaction between Player and Game. I don't have a Game object yet, but Ruby's 'duck' typing allows me to pass the test class to the Player and have it respond to the messages that Game should respond to. Incidentally this is known as the Self-Shunt pattern. I often start with this and later refactor to use a real or mock version of the object.

What should it respond to? It seems to me that Player only needs to be able to 'spit' on a pile to pass this test. First I'll, wait, always run the test first to watch it fail. Okay it threw a NameError which means I haven't defined a Player class yet. Next it'll need a constructor with one parameter, an accessor for @hand, and a method 'play'. With that in place

class Player
  attr_accessor :hand
  def initialize( game )
  end
  def play
  end
end

the test is now failing as expected.

I'm thinking the simplest thing that could possibly work is

def initialize( game )
  @game = game
end
def play
  while(!@hand.empty?)
    @game.spit_on_one(@hand.pop)
  end
end

I'm assuming that game has a method 'spit_on_one'that takes a card. I'll make the SpitPlayerRules class do that for now.

def spit_on_one( card )
  @pile_one << card
end

I'll run the tests. Green bar.

Now I can think of a few more tests that would help flesh out the interface between Game and Player.

What happens when player makes an invalid move?
How does Player draw from its stock pile?
How does Player get notified of the end of game play?
Does player notify Game when its out of cards?

All of these questions to answer and I'm out of time to write this. I'll ponder them. Maybe somebody like Jim will virtual pair with me again, and help me figure out where to go next. Until next time here is the code listing.

#--------------------------Spit.rb
class SpitPile
  def initialize( first_card )
    @pile = [ first_card ]
  end
  def play( card )
    if in_sequence?(card)
      @pile << card
      return true
    end
    false
  end
  def to_s
    @pile.join(', ')
  end
  def top_card
    @pile.last
  end
  def in_sequence?( card )
    (card - top_card).abs == 1
  end
end

class Player
  attr_accessor :hand
  def initialize( game )
    @game = game
  end
  def play
    while(!@hand.empty?)
      @game.spit_on_one(@hand.pop)
    end
  end
end
#-----------------SpitTest.rb
require 'test/unit'
require 'spit'

class SpitPileRules < Test::Unit::TestCase
  def setup
    @pile = SpitPile.new( 2 )
  end
  def test_accepts_card_of_next_higher_rank
    assert @pile.play(3)
    assert_equal "2, 3", @pile.to_s
  end
  def test_accepts_card_of_next_lower_rank
    assert @pile.play(1)
    assert_equal "2, 1", @pile.to_s
  end
  def test_rejects_card_of_same_rank
    assert !@pile.play(2)
    assert_equal "2", @pile.to_s
  end
  def test_rejects_cards_of_non_consecutive_rank
    assert @pile.play(3)
    assert !@pile.play(1)
    assert_equal "2, 3", @pile.to_s
  end
end

class SpitPlayerRules < Test::Unit::TestCase
  def test_run_without_draw
    player = Player.new(self)
    player.hand = [ 2, 3, 4, 5, 6 ]
    @pile_one = [7]
    @pile_two = [7]
    player.play
    assert_equal [7, 6, 5, 4, 3, 2] , @pile_one
  end

  # game methods
  def spit_on_one( card )
    @pile_one << card
  end
end

TDDing a Card Game part 1

2006-02-08T07:53:00.000-08:00

In my previous post I committed to writing an entry a week in this blog. Coming up with content is hard! Of course since I've called this my Software Engineering blog I've narrowed the topic down somewhat.

One important technique in any programmer's toolkit is Test Driven Development. Contrary to the name, TDD is a Design technique. We write a test to specify and constrain the problem at hand. Then after watching it fail, we write the simplest code that will cause the test to pass. Finally, and most importantly we refactor to eliminate any duplication that we created in the previous step. We do this loop several times and soon we've designed and coded a piece of software. For the next few entries I'm going to use TDD to create a card game.

Spit, also called Speed, is a card game I used to play when I was younger, though I always played the five card hand variant. I'm going to focus the five card hand variant because it's what I know. Others have programmed versions of the game before. I never have though, so this ought to be fun.

The layout is as follows:

 stockpile ------> 15 cards

10 cards    1 card          1 card    10 cards <---- spit piles and spit reserves

 stockpile ------> 15 cards

The object of the game is to place all of your cards from your stockpile into the spit piles before the other player. This is not a turn based game. You may only have five cards in your hand at time. Cards of the next higher or lower rank may be played from your hand to either spit pile. If both players are stuck you simultaneously flip the top card from the spit reserves on to the spit pile.

As this post is already pretty long we'll just tackle the rules for playing a card on the spit pile. My language of choice at the moment is ruby. Ruby's Test::Unit is the ruby member of the xUnit family.

We start with a test.

require 'test/unit'

class SpitPileRules < Test::Unit::TestCase
  def test_accepts_card_of_next_higher_rank
    @pile = SpitPile.new( 2 )
    assert @pile.play(3)
    assert_equal "2, 3", @pile.to_s
  end
end

I've named this test case SpitPileRules because it is specifying the rules of play for the spit pile. The first test shows we can play a card of higher rank. At the moment cards are represented as numbers because in Spit we don't care about the suite. We're checking the contents by looking at the string representation of the pile. Also, we expect the SpitPile#play to return a boolean showing success. The next step is to pass this test as quickly as possible, wait first we run it to watch it fail. Okay, now we can pass it.

class SpitPile
  def initialize( first_card )
  end
  def play ( card )
    true
  end
  def to_s 
   "2, 3"
  end
end

That passes. Now we refactor to remove duplication. What duplication, you might ask. Well, the string in SpitPile#to_s duplicates the expected value in SpitPileRules#test_accepts_card_of_next_higher_rank. So I'll replace it with a member variable, and make sure the variable is populated correctly.

class SpitPile
  def initialize( first_card )
    @pile = [ first_card ]
  end
  def play ( card )
    @pile << card
    true
  end
  def to_s 
    @pile.join(', ')
  end
end

Run the tests, and it still passes. What happens when we add a card of lower rank? Let's write the test.

def test_accepts_card_of_next_lower_rank
  @pile = SpitPile.new( 2 )
  assert @pile.play(1)
  assert_equal "2, 1", @pile.to_s
end

Okay, let's make that pass. Wait, first I'll run the test, and it passes. That's fine, that happens very rarely to me, but as SpitPile stands it passes this new test. On to the next test. We could either check if it rejects cards of non consecutive rank or if it rejects cards that are of the same rank. I think I'll do the same rank first.

def test_rejects_card_of_same_rank
  @pile = SpitPile.new( 2 )
  assert !@pile.play(2)
  assert_equal "2", @pile.to_s
end

Run that, and it fails. Good. Now we make it pass.

def play ( card )
  if card != @pile.first
    @pile << card
    return true
  end
  false
end

Passed. Okay, now we have an opportunity to refactor. This time we see duplication in the test specifically all three tests have:

@pile = SpitPile.new( 2 )

Let's factor that out into a setup method.

class SpitPileRules < Test::Unit::TestCase
  def setup
    @pile = SpitPile.new( 2 )
  end
  def test_accepts_card_of_next_higher_rank
    assert @pile.play(3)
    assert_equal "2, 3", @pile.to_s
  end
  def test_accepts_card_of_next_lower_rank
    assert @pile.play(1)
    assert_equal "2, 1", @pile.to_s
  end
  def test_rejects_card_of_same_rank
    assert !@pile.play(2)
    assert_equal "2", @pile.to_s
  end
end

After running tests I'm sure it's still passing so I will move on to non consecutive cards.

def test_rejects_cards_of_non_consecutive_rank
  assert @pile.play(3)
  assert !@pile.play(5)
  assert_equal "2, 3", @pile.to_s
end

It fails. Now we can make it pass.

def play ( card )
  if (card != @pile.first) and ((card - @pile.first).abs == 1)
    @pile << card
    return true
  end
  false
end

That passes, but I just noticed that it might not pass if I change that case like this:

def test_rejects_cards_of_non_consecutive_rank
  assert @pile.play(3)
  assert !@pile.play(1)
  assert_equal "2, 3", @pile.to_s
end

It doesn't. The reason is I'm adding card to the end of the pile with <<, but I'm checking against

@pile.first

so I'll change that to

 @pile.last

and we're green. Now it's time to refactor. The obvious duplication of @pile.last can be factored out to something more meaningful.

def play( card )
  if (card != top_card) and ((card - top_card).abs == 1)
    @pile << card
    return true
  end
  false
end
def top_card
  @pile.last
end

Tests are still green. Next we'll clarify what those conditions mean.

def play( card )
  if in_sequence?(card)
    @pile << card
    return true
  end
  false
end
def in_sequence?(card)
  (card != top_card) and ((card - top_card).abs == 1)
end

Okay. I've spent about two hours on writing this article including about 15 minutes of coding. I see a few directions I can go from here. I think SpitPile#in_sequence? really doesn't belong to SpitPile. It seems like it should be on Card, or Deck or something like that. Also, I'm not entirely comfortable with to_s. I think it may be tying the rules of a SpitPile to closely too a UI, but it will do for now. Now that we have SpitPile should we create a Player class that can interact with SpitPile, or a Game class that controls the flow of the game around SpitPile? Do we make some of the other piles as independent classes? I'll decide soon and work on it in the next entry.

Thanks for following along.

Why I'm Starting to Blog

2006-02-01T07:19:00.000-08:00

The other day I purchased My Job Went To India (And All I Got Was This Lousy Book) 52 Ways To Save Your Job by Chad Fowler. It's a great book on how to architect your career for software engineers. Each chapter ends with an Act On It section that encourages you to apply the advice provided. My shiny new blog is a result of an Act On It.

Chapter 12 is about finding a mentor, and the Act On It section encourages you to Mentor Yourself by choosing someone you admire as a role model, list and rank their most important attributes, and rate yourself as they would rate you on those attributes. Then you can determine what you should work on.

I did this activity, and determined the attribute of my chosen mentor that I most need to work on is a prolific writing habit. This includes blogging, web articles, contributions to mailing lists, and books. I've resolved to do the following:

Get a blog <Check />
Post at least once a week to said blog
Respond relevantly to at least one mailing list post per day
Take the next opportunity to write a technical article

So there you have it, why I'm starting to blog in a nutshell. Many thanks to Chad for the book that will change my career.