Quite a few people have been writing about their exploits with Test-Driven Development over the past few weeks and months. Oren Ellenbogen has been writing several articles on the basics of TDD, Ron Jeffries has been TDD'ing a sudoku solver, and Scott Hanselman, Phil Haack and Roy Osherove continue to add more thoughts of their own to the subject. Roy has even started a blog on writing a book about test-driven development.

Given my attention deficient aptitude for getting distracted by something else before getting started on a project, Oren's description of TDD as 'Code little, think, code little' seems good for me. And with the repeat test run feature now up and running in Jamie Cansdale's TestDriven.NET 2.0, using nUnit in VS2005 is even easier than before.

I haven't seen anyone work with XML in a TDD blogging series yet, so I'm going to TD-develop a .NET 2.0 app which extends the schema-to-class functionality in xsd.exe. I've picked this for a number of reasons.

  • I've already had a go at this in the past but didn't get very far
  • TDD also functions as a great way to learn new technologies \ algorithms bit by bit. (Ron's Sudoku solver being a case in point)
  • The default behaviour in xsd.exe changed a little between .NEt 1.x and .NET 2.x which means that documentation on this kind of app such as this well thumbed doc provided by Dan Cazzulino on MSDN may be out of date now and TDD will help pick up the differences as we go along.
  • I've encountered a bug or two with the XmlSerializer in .NET 2.0 that requires tweaking the class file which xsd.exe generates and it would be useful to do this automatically rather than as a postfix.

I'm going to use the first few tests to

  • Set up a nice testing framework for testing boundary conditions as we encounter them.
  • Get to grips with the internals of the XmlSchema and CodeNamespace classes that we might not already have.

We can also bear in mind the simple condition that in these initial tests, our code should return the same as if we used xsd.exe on a schema file, so we can generate tests from that as well. Now some might invoke the first acronym of TDD - YAGNI - or 'You ain't gonna need it', which may be true here, but as we're also going to learn how schemas and code namespaces map to each other in the process, I'm happy to make the trade off.

Right then, onto the first test...