Sunday, 9 June 2013

A real life project: The Walking Skeleton

Using tests to create The Walking Skeleton

Ever been working on a piece of software, think you have it finished only to have your heart broken my some integration or deployment problem? The first step in the GOOS book is to use tests to create a walking skeleton in the hope of avoiding these problems. It's really great advice for any software project.

I created two tests to drive out the walking skeleton, starting with the simplest behaviour that I think the game can have.

A game that no-one joins

Test number 1, a game that no-one joins. Doesn't sound like much, but when you take into account that we want something that can be deployed from this there's quite a bit of work. Implementing this test means we need the Poker Game app, a runner to control the app and a way to detect UI output from the application.

I need to create these components to get this test to pass and when I do I should have something like this.

The Poker Game Runner allows the tests to interact with the Poker Game. It will start the application and acts as my main point of interaction with the application.

The Poker Game is the application itself. After this test it will do nothing more than display a console message that the game is starting, wait for a while and display a message saying that it is quitting because there are no players.

The Console Scraper allows me to read whatever is written to the console by the Poker Game. I can use this in the test to verify that the correct messages are being displayed.

It's not the whole picture yet though so I need to introduce another test.

A game that one player joins

The first test doesn't quite give us the walking skeleton we need because there's one other very important component that doesn't get exercised by this test, the XMPP server. To get that I introduce a second test, a game that one player joins. It still is not enough to do anything really interesting, but to pass this test I will need the player to communicate with the dealer. Implementing this behaviour means setting up an XMPP server and having a player communicate with the dealer through it by asking to join the game.

With the XMPP Server added I can now verify that there is some kind of interaction between the dealer and the players.

To finish this test I create a Fake Player that I can control within the test. At the end of this test, the Poker Game will register with the XMPP Server, the Fake Player will ask to join the game through the XMPP Server and the Poker Game will react by displaying that the player has joined.

Final Note

I need to start thinking about the next test now, and that's not too easy. Normally at this stage in development I begin to wonder how many acceptance tests I'll have and how complicated they will be. I could really test the whole system by adding more and more acceptance tests, but I could see that getting ugly further down the line with complicated and buggy tests.

So, I'm wondering, how much do I test with acceptance tests and when do I decide to test directly on the class with the behaviour? From my understanding of the GOOS book, in my test where a player asks the dealer for permission to join the game, I shouldn't care what message is sent to the dealer. The point is just to introduce 2-way communication between the dealer and a player and any message can do that. I'll test the dealers reaction to messages directly on the dealer when they are needed.

No comments:

Post a Comment