Seems the last post has hit a chord, so I’m supplementing it with actual links. Since I had a friend who runs the testing for a .NET shop in another window, I’m going to just archive the links being tossed back and forth here.

  1. Unit test. Unit test. Unit test. Yes, an application is more then just the sum of its nicely tested units, but it can also be far less.NUnit is the grand daddy, but there is also MbUnit as well as a bunch of plug-ins for Visual Studio
  2. Unit tests are more or less useless unless they can be run from outside the IDE. Make it so.NAnt; especially with the nunit2 task. There is also a way to run NUnit tests from within MSBuild
  3. Tie your now-running-outside-of-the-ide unit tests and your versioning system together through Continuous IntegrationCruiseControl.NET and Draco.NET are two such beasts
  4. Introduce inspection tools, both source and compiled, into the CI mix – There are a number of tools that fall into this category. You will want to figure out what you want to track and make decisions from there. I’d start the filter process with the following:
  5. Explore using Test Doubles to remove relationships from your tests (and as a by-product, make them faster) – Again, there are a number here and I’m sure the relative merits of each have been hashed out elsewhere, but here are two obviously named ones: .NET Mock Objects and NMock
  6. Flag places that are ripe for refactoring both in the code (perhaps with a big REFACTOR comment) and in the bug tracking system. Follow this up with starting to refactor the easy places first. The difficult ones likely will have a greater impact, but they are also riskier and can likely wait until your safety net is a little more robust (more unit tests for one, a professional tester for another).
  7. Start doing peer code reviews, and actually action on the items discussed. Doing code reviews without the follow up is just a waste of developer time.

Once you have these things in place, you really are ready for a fulltime tester. Nothing drives them/we/us more bonkers is to be given the green light to test a certain build to be thwarted by a really big, obvious bug. The above steps should go a long way in preventing that.