Unit testing

Do you want to know as soon as your new code breaks some older piece of code, either yours or someone else? I’m sure we all would like that. Well, Extreme programming answer to this is automated unit tests. The idea is that you have a set of classes testing your code; you write a test for each function you have, checking the expected result against actual results. Once you change any part of the code base or add new code, you run the test suite and right there you find out if there is anything broken, the failing tests also show you exactly which part is broken. If all the tests pass, then you know for sure you changes are ready to be integrated with the rest of the system.
The biggest resistance to dedicating any amount of time to unit tests is a fast approaching deadline. But during the life of a project an automated test can save you a hundred times the cost to create it by finding and guarding against bugs. The time it takes to find and fix a bug as you are developing your code is much less than finding it and fixing it after you are done and the system is being tested by the client. The harder the test is to write the more you need it because the greater your savings will be. Discovering all the problems that can occur take time, so to have a complete unit test suite when you need it you must begin creating the tests as you build the code.
Examples of unit test frameworks are NUnit (http://www.nunit.org/) for .net and JUnit (http://www.junit.org) for Java