How do you decide what to test in your test suites?
I'm an intern working on a project that has the potentia开发者_开发技巧l to introduce a lot of bugs at a company with an extremely large code base. Currently the company has no automated testing implemented for any of their projects, so I want to begin writing tests for the code as I go so that I can tell when I break something, but I have a hard time developing an intuition for what is worth testing and how to test it. Some things are more obvious than others: testing string manipulation functions isn't too tough, but what to write for a multithreaded custom memory manager is trickier.
How do you go about designing tests for an existing codebase and what do you test for? How do you figure out what underlying assumptions the code is making?
Answer to most of your questions http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052
No easy answers for you I'm afraid. That is just a tough spot to be in.
The method to be applied is
- identify regions that deliver the most bang-for-test-buck. (This is something that you have to come up with - unique to your situation).
- Spend time getting to know the region. Identify interactions of this region with the rest of the code base.
- Document the same using tests - these act as a regression "vice" that will hold your software in place while you make subsequent changes
- Now you've a safety net to work above. You can now start making your enhancements/fixes/changes using a TDD approach.
The idea is slowly islands of the codebase will emerge above the safety net till you reach a point of diminishing returns. Michael feather's WELC book as posted by Pangea above is a must-read if you're venturing into this area.
A similar question has been asked and answered here
Some quick thoughts from me:
- At the beginning, add tests for new written code, either in new project or for changes on a existing project.
- Don't touch code that is running and is not changed.
- concentrate on functionality that is often used or that is critical.
The subject is really manifold and maybe you should try to get a training to get an overview. Assuming you are in the US, you can have a closer look here. Here is their course content.
They have also a long list of useful resources.
精彩评论