Test-Driven Development, part 2

Let me start off by saying, I’m new, I don’t know what I’m doing, and it is always possible I am a little wrong, a lot wrong, or even all the way wrong…

My understanding of Test-Driven Development is this: Start from scratch, write a failing test, run the test, write the simplest code that will make the test pass, write another test, etc. There is some nuance there that is hard to put into words but easier to put into practice. Usually your second failing test will require rewriting your simplest code from the first failing test into actual working code. Also, you want to keep writing tests about the same general thing until you are satisfied that thing is finished (or as finished as you need it for now). There will be some examples shortly.

I decided that I needed a very concrete and simple project to help me wrap my head around TDD. I have chosen to build the game of blackjack, with one player and the dealer. A fairly simple game with simple requirements. The dealer doesn’t even need “real” A.I. because the rules dictate the actions the dealer must take. If one is to think about how to go about playing a game of blackjack, it becomes very easy to list the steps in order. My list looks like this:

  1. Produce one or more decks of cards
  2. Combine those decks into a shoe of cards
  3. Shuffle the shoe
  4. Initial deal, 2 cards, player first
  5. Check for dealer blackjack
  6. Player input, check for bust
  7. Dealer takes cards as per the rules, check for bust
  8. Determine winner

For now I am not including betting. Point 6 breaks down into another list of choices like split and doubling down. But that’s the broad outline, and the order in which I think I am going to tackle the programming. So the first step is to have a deck. At this point I have no code at all, which means it is the perfect time to write my first test!

(I’m using mocha and node.js’s assert style. To get assert in there I added this line of code

var assert = require("assert");

)

The whole thing gets wrapped in a describe block, and then each logical separation gets a nested describe block too. Inside of those are the it blocks, the tests themselves:

describe('Blackjack Game', function(){
    describe('deck', function(){
        it('should exist', function(){
            assert.equal(typeof deck, 'object');
        });
    });
});

There it is. In the command line, I type “mocha”, hit enter and I get…

Blackjack Game
deck
1) should exist

1 failing

1) Blackjack Game deck should exist:
AssertionError: ‘undefined’ == ‘object’

Just the failing test I was looking for. I haven’t created deck, or anything else yet. Let’s fix that.

var deck = [];

Re-run the test, it passes!

Blackjack Game
deck
√ should exist

1 passing

That was simple, but that deck is empty, we wouldn’t play with an empty deck, would we? We need a deck that has 52 cards, let’s test that.

it('should have a length of 52', function(){
    assert.equal(deck.length, 52);
});

And of course, that test fails. Remember, failing is a good thing! So I filled the deck array up with 52 members. On some level it is probably important to know what those members are and to test against that as well, but I took the liberty of moving on. I can always come back once that is important.

In the same way, I wrote tests for the shoe and then built the shoe to make the tests pass. This image from my last post has the whole set of tests:

mocha

I lumped a set of three “subtests” into one test that checks that the decks add up to the right number of cards. I don’t know if that is the right way to do it, but it works well enough. Below is the totality of the blackjack code I have written so far. Not very impressive, but it all does exactly what I want it to do, for now. Next up is shuffling the shoe. I have to figure out how I am going to test that and then how I am going to actually shuffle. I copied a shuffling algorithm from a stack overflow post a few days ago that I know works, but I didn’t really understand how. I need to sit down with that for a while and see if I can make sense of it. I think the test I will have to compare, somehow, the starting shoe array against the shuffled shoe array. The details elude me, but I am working on it!

testedCode

Advertisements

One thought on “Test-Driven Development, part 2

  1. Pingback: TDD Nitty Gritty | mushiwulf learns to code

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s