I would advise you to learn about Refactoring, Test Driven Development, and the various unit testing modules (NUnit, Visual Test, CppUnit, etc.). I also learned how to incorporate automatic unit testing into your continuous integration builds.
Ultimately, if you can prove that your code does what it claims to do, you don’t have to be there to answer questions about why and how. If an maintainer comes in and tries to “fix” your code, they will know right away if they break it. Tests written around requirements (use cases) explain to the maintainer that your users wanted to do this, and give a small working example of how to call it. Think of unit tests as functional documentation.
Test Driven Development (TDD) is a newer development approach that starts with requirements when you start by writing a test before writing code. Then you write enough code to complete the test. You must stop before writing additional code (which you will never need), because you will reorganize it later if you find that you really need it.
What makes TDD cool is that a poor interface (like one with a lot of dependencies) is also very difficult to write tests. It is so complex that the encoder rather reorganized the interface to make it easier to test. And this refactoring simplifies the code, removes inappropriate dependencies or groups related tests together to facilitate testing, thereby improving cohesion. Having done this immediately to the developer, when he writes a poorly interacting module, the developer adheres to the architecture and gravitates to the principles of tight cohesion and free communication. Good interfaces are a natural result. And as a bonus, once you pass all your tests, you know that everything is ready.
John Deters Jun 02 '09 at 22:18 2009-06-02 22:18
source share