I would recommend googletest: "Google C++ Testing framework" to create test modules for your applications.
Here's the description from project's page:
Google's framework for writing C++
tests on a variety of platforms
(Linux, Mac OS X, Windows, Cygwin,
Windows CE, and Symbian). Based on the
xUnit architecture. Supports automatic
test discovery, a rich set of
assertions, user-defined assertions,
death tests, fatal and non-fatal
failures, value- and
type-parameterized tests, various
options for running the tests, and XML
test report generation.
I haven't used this tool myself, but you can read an overview of this framework -- there is a good introductory paper on IBM's developerWorks site: http://www.ibm.com/developerworks/aix/library/au-googletestingframework.html
Cheers.
Absolutely.
Refactoring should be done on a working and "passing" project. When all your tests (at the unit, system, and acceptance levels) pass, you know that your product meets requirements. When you refactor, you can continue to confirm that all tests continue to pass. If any test begins to fail, then you did something wrong and need to correct it. If you have failing tests, you should correct those before refactoring so you can always ensure your refactoring isn't changing the functionality of the system.
This is also a perfect time for refactoring, assuming you have the time and resources to carry out the refactoring and still deliver on time and budget. Refactoring now will make it easier to understand and maintain your system, so as you add even more new features, it becomes easier. You need to fight against code rot and software entropy.
As Joel Etherton points out in the comments, you need to manage the scope of refactoring. Focus on refactoring the parts of the system that you will soon be adding features to, performing refactorings that will make it easier to work with or add the new features. The use of static analysis, metrics tools, and code reviews can help you identify areas that are most critical. You don't want to miss deadlines because you were refactoring - you still need to continue to add value to the customer.
You mention the customer not seeing value in refactoring. Typically, the customer doesn't care about the quality of the code, but of the product. Refactoring will make it easier for you to maintain a high product quality and keep delivering a product that meets the changing needs of the customer. Try to negotiate time to refactoring into your schedule (customer wants X features in Y days, try to see if you can't get Y+Z days or X-N features so you can spend time on design, refactoring, and implementation), if you can.
Best Answer
The scope can be changed at anytime, provided those changing accept the required changes to budget and schedule. You can't stop people from continually trying to change the scope until they realize it costs money, providing a few estimates of the cost for requested changes from higher-ups will help them make that connection. Doing this is unlikely to stop them from requesting changes, but it is likely to stop them from complaining when you deny those changes, and will help you identify the changes you need to make when they understand the cost of that change.