I'm a big fan of Test Driven Development and so it was great to sit in a TDD session run by Niel Rodyn (Author of Extreme .NET & Microsoft MVP).

While there was nothing new for me in this session, it was really good to hear things from someone else's perspective.

I've jotted down some of his comments here (without any real editing) for you to mull over:

  • Team development should based around getting good people, then figuring out the process/methodology to use, and then finally look at the tooling.  The common behaviour is to do the opposite.
  • A lot of the reasons for project failure is due to poor quality.  And quality problems are preventable.
  • TDD is all about frequent feedback (as is agile project mgmt).
  • All software projects start with 0 bugs.  By adding very small increments of code and keeping the whole thing tested, we can ensure that the number of bugs remains at 0.
  • Good coverage by TDD is a great debugging tool - why? because unit tests are highly focused on small sections of code, so locating a problem is really easy.
  • Unit tests should never go outside the class boundary.  Some think unit tests shouldn't be outside the boundaries of a method.
  • Large code will have hundreds of thousands of unit tests.  This requires dedicated test servers sitting on the back of CI builds.
  • TDD doesn't mean we can stop other types of testing.
  • A single passing test proves nothing in and of itself.  It's by having a large number of tests that make TDD worthwhile and proves the software works well.
  • TDD encourages thinking about edge conditions, exception handling, memory faults, network timeouts, etc.
  • Good Tests are ATRIP ([A]utomatic, [T]horough, [R]epeatable, [I]ndependent, [P]rofessional)
  • Running tests in random order is a good way to test repeatability.
  • TDD is a great way to go fast - no code debt & high confidence.
  • Bug fixing is not refactoring.  Refactoring changes structure of code without changing functionality.  Fixing bugs changes functionality and is therefore not refactoring.
  • Why write tests first? It makes us think about design first.  Scopes our functionality.  It tests what we should do, instead of testing what we did - this is critical.
  • Higher quality software dramatically lowers the maintenance and support costs.

Tooling:

He uses NUnit because it's faster the MSTest in Visual Studio 2005 Team Edition, and also because most people only have VS2005 Pro.  Visual Studio 2008 will have testing in the pro edition and if it runs as fast as NUnit does at the moment then he may switch.

He uses NMock for mock objects.  Personally I prefer RhinoMocks but NMock is great as well.