A joint post by Llewellyn Falco and Michael Kennedy
[Update: Get
the videos and additional downloads for this webcast.]
As a follow-up to our "
Avoiding 5 Common Pitfalls in Unit Testing" article we did a webcast where we took a problem from the audience and solved it live and unrehearsed on stage. These kinds of performances are always a risk but that's part of what makes them fun.
Of course, the question is could we have done it better? Here's your chance to try it for yourself (details below).
The Problem:
Our viewers chose to have us build the game
Space Invaders. The first thing we had to do to sketch out a basic scenario we could implement. We started with a picture to remind what Space Invaders even was:
This was too big of a scenario for us to tackle in the allotted 40 minutes for programming. So then we started by creating a simpler scenario which we sketched out on the "whiteboard":
Click for full size image.
Flushing Out the Scenario:
In doing this, a couple of things were revealed about the game.
First, we wanted to make the tank and aliens all be the same size so we could put them on a grid. But then we saw that our bullet wouldn't fit that story, so we introduced the idea of relative sizes. We also realized that even though we drew the block, it was too complex for the first scenario and it would have to wait.
Notice that as we started writing the scenario in English, there are mistakes, irrelevancies, and problems with the order. This is OK. The thing to remember is that all of this was done for the sole purpose of creating a recipe for a scenario we could test. That scenario is the following:
[TestMethod]
public void TestSimpleKill()
{
// 1. Create a 15x10 board.
// 2. Place a 3x2 tank at 1x8.
// 3. Place a 2x2 alien at 7x3 heading west.
// 4. tank shoots
// 5. advance 4 turns
// 6. not won
// 7. advance
// 8. win
}
Now that we had the recipe, we could go about writing the code.
Here's your chance to play at home!
- Set your timer to 40 minutes.
- Create a new test project.
- Paste that method above.
- Translate the comments into code.
If you believe there's a better process, we invite you to try that as well.
We made it to step 4 during our presentation (download code below) and estimate another 15 minutes would have had the whole scenario done, tested, and well-factored.
Stories vs. Requirements (stories win):
We'd like to point out a couple of things about the story. First, it was quick to write the story. We did it in 5 minutes. Second, it translates well to code because it has behavior and objects working together. Let's compare that to the requirements that this story flushed-out.
- Need a board
- Boards should have width & height
- Boards contain game objects
- Game objects have a witdth, height
- Game objects have the ability to move each turn
- Aliens move either left or right each turn
- Bullets move either up or down each turn
- Bullets are 1x1
- Tanks are 3x2
- Aliens are 2x2
- The game is not won until all the aliens are killed
- The game is won if alll the aliens are killed
- An Alien is killed if it is hit by a bullet
- Tanks can fire
- Firing with a tank creates a bullet going up from the space directly above the tank
|
Now we want to point out that this requirements doc is much hard to understand than our story. For example, if you were to add more requirements (e.g. an alien also shoots) is that easy to determine whether we have complete requirements? It also takes much more effort to create and especially to tell if it is complete. People aren't made to handle requirement documents well but we are story-telling machines. We embrace this in our coding techniques.
We'd also like to mention some of the tools discussed at the end.
For remote collaboration we use:
Skype (audio / video)
VNC for screen keyboard sharing
RDP (windows remote desktop) -- requires Windows 2003/2008 server for pairing.
Source Control:
TortoiseSVN
TortoiseGit
Developer Tools:
Resharper
CodeRush
Testing Tools:
MsTest (in Visual Studio Professional and up)
NUnit
NCover
TortioseDiff
Approvals Tests
Approvals Tests CodeRush add-in
Rhino Mock
TypeMock
If you try this scenario yourself, please leave a comment about your experience.
Download the code and slides from the webcast here:
Code: TddWithLlewellynAndMichael.zip
Slides dmtdd.pdf
Cheers -- Michael and Llewellyn