This is the log of a sample project from a small band of software engineers eager to learn better ways of working and new technologies. We've decided to use .NET 3.0 to create a Battleships game.

The Quest For The Perfect Project

Thursday, 8 February 2007

Getting into the swing of it

I'm finally coding and it feels great to get back into C# and .NET land. The first few weeks of this project were spent discussing and creating a rough product backlog with details of tasks we'd like to do. I was concerned that with us trying to do "the perfect project" that we might end up in analysis paralysis and never actually get started, but that doesn't seem to be the case.

I've just started fleshing out the domain classes, it's very early stages - but it's coding at last! I was determined to do things properly though. I've not really experienced much TDD in .NET it wasn't until I started writing Java that I became an Agile adopter. TestDriven.NET has various nuances to the TDD framework that I was used to using in Java but I'm slowly picking it all up.

When you're up against deadlines at work, you sometimes take the easy option and start coding straight away not really doing the whole TDD properly, just tacking on the unit tests afterwards. I did however make more of an effort to write a test first when we came across bugs because it was a great way to verify that you'd actually fixed it.

One simple TDD example from Battleships:

I've identified one of the domain classes to be a ship and before I even created the Ship class, I created the test class initialising x and y coordinates for the ship.
public class ShipTest
   public void ConstructShip()
       Ship ship = new Ship(6, 8);
       Assert.AreEqual(6, ship.X);
       Assert.AreEqual(8, ship.Y);
The test doesn't compile until I expand this further and create the Ship class. In true TDD style, you'd literally do a compile after each stage.
  1. Construct the ship.
  2. Fix compile errors by creating a ship class and basic constructor.
  3. Test for some values (x and y coordinates).
  4. Modify the ship to give you the coordinates.
public class Ship
   /// <summary>
   /// The X coordinate on the board for this ship
   /// </summary>
   int x;
   public int X { get { return x; } }

   /// <summary>
   /// The Y coordinate on the board for this ship
   /// </summary>
   int y;
   public int Y { get { return y; } }

   public Ship(int x, int y)
       this.x = x;
       this.y = y;
Now that we have created the class, the unit test to construct a ship works. It's progressed from there, in that we now have a length for the ship and an orientation value, but this just demonstrates how basic the unit tests were at the very beginning.
I am really starting to see the benefits of doing it properly though. I've been quite strict on myself, even with these straightforward domain classes that I'm creating at the moment. I'm writing a test even before I've created the class and although at first I felt a bit silly, I stuck at it and it's now really good fun. I'm seeing the benefits already and I'm confident that the code I'm producing is of a higher standard than if I'd not had unit tests at all. You spot the errors quickly because it's staring you right in the eyes when you get failed unit tests.

The last time I looked at C#, it was in .NET 1.1. I'm actually finding it a lot easier to works with C# 2 and the .NET 2.0 framework after my brief experiences with Java. I'd completely forgotten about the old way of using the .NET collections and I slipped right into the groove with C# generics - they're just fabulous.

I'm so glad Microsoft have taken a few hints from Eclipse, the IDE is much better than 2003, very slick - though I do miss the organise imports. So if you know any of the Microsoft IDE developers, give them a little nudge from me ;).

All in all, it's lovely to be back in .NET land and I can't wait until this project really gets going.




It might be interesting for those reading this blog to post code snapshots. Even if the tests look trivial or make you feel silly, I think they might be helpful for people new to TDD who are still looking for the hot spot :-)

Thanks for the comments. I'm reworking the post to take this into account.

You mentioned Domain objects, it might also be worth ellaborating here a bit more. Some people don't understand the distinction between their DAL and domain objects. I actually thought that this blog WOULD focus more on these types of things, such as using TDD or DDD etc, rather than specific problems encountered while coding. Agile is a good start.

That's a good point. So far it's been pretty poor from my side of the fence, partly because I've been ill for the last three weeks. I'll try to rectify that tonight with a post about traditional n-tier designs, variations, and what we're likely to do. Watch out for more later on (hopefully). If you're lucky, there might even be pictures :)
"I do miss the organise imports"

Emma, you need a copy of resharper. I couldn't imagine doing TDD without it. Sooo much easier.
Hi Jon,

Why did you use properties with backing fields for X and Y but not auto properties?

Thanks man.
@Anonymous: This was back in early 2007, well before automatic properties were available.
Thanks Jon, didn't realize the date :O Sorry for reviving this back from the dead.

Add a comment