- build it - First, figure out how to build it, and then script that build process. After that, it should be easy to automate the builds.
- automate it -Your goal is to automatically build and test the entire product on a clean machine with an absolute minimum of manual
intervention. Document all the build steps and make this documentation publicly available. - test it - Figure out what the code does, then begin testing by writing mock client tests for it. Once you have the project building cleanly, you’ll want to confirm that it works. In order to write the tests, you’ll have to learn exactly what the product is supposed to do (no surprise there). Mock client tests are a good starting point: they test the broad functionality of a product because they act just as a product user would.
- test it more - Figure out the product’s innards (things such as structure, flow-of-control, performance, and scalability), and write more tests for it. Unless the product is completely unused, there will be bugs you’ll need to fix (or at least document) or enhancements you’ll have to make. Normally these changes are a pretty scary thing to do to legacy code, because you’re never quite sure what you’re going to affect when you make a code change. But you can do this fearlessly because of the mock client tests you wrote as a safety net; they’ll keep you from breaking things too badly. Write a new test for every bug you fix and for every enhancement you add to the product. The type of test you write will depend on what you’re changing (e.g., a unit test for a low-level internal change, or a mock client test for a new feature). At this point you’re treating the legacy product in the same way you would any other product you support.
I find that testing a new code base forces me to understand the system. I suppose the added benefit of writing tests for known bugs forces me to understand the defect tracking system as well.
No comments:
Post a Comment