OK so there’s a thing called test-based development techniques. Essentially it means that if you want to write a piece of code, you first write a test piece which defines an example of input variables and corresponding output varaibles. It then calls the function you want to write and retrieves the ouput from that function. A simple Assert.IsEqual() then compares your actual versus expected output and your unit test fails if this comparison is False. So with this approach you write your code until your test passes. And then you create more tests until you have your final product.
You unit test can be done easily in Visual Studio 2005 by adding a Test project. It also provides wizards for coding test based on existing function definitions. You can also run your unit test within the IDE.
This is all peachy, but totally useless unless you can make it scale. So say for example you slap a code versioning system such as CVS or Subversion in there for managing your code base with multiple developers checking things in and out. Now IF you trust your developers 100% then you won’t be worried about one developer checking in code that breaks another developers code. But if you’re the build master you tend to trust no-one. So what you do is you use Cruise Control and Nant to do automatic checkouts and mintely builds and unit testing of your software. You also tell your developers that if you break the unit tests you stay till its fixed. AND, you insist that nothing is checked in on Fridays.
This is of course easier said than done.
I hope to add some more details to how CVS, Nant and Cruise control operates- moreso for my own notes since I’m pretty sure people out there have done it already.
I should really Google it. TBC.