Large scale softwareTelecommunication device10+ years old1,000 people10,000,000 lines of code in one buildC, SDLSome very complicatedThousands LOCs functionsCyclomatic complexity > 50.Duplicate rate > 100%!
PRINCIPLE 1KEEP IT VERY SIMPLE, VERY STUPID It is not that the more test cases the better Actually, it is on the contrary, the less the better. The purpose of UT is to facilitate change It can only facilitate change if it survive Therefore, it needs maintainability So, it needs to be simple "The only way for humans to deal with complexity is to avoid it ..."
PRINCIPLE 2DONT TRY TO ADD GOOD UT TO BAD CODE
Setup the framework To setup the framework for legacy code can be very challenging. Choose the test framework We use CppUTest Ask for performance
Domain Modeling Reverse engineering to clarify the concepts used in the legacy code And their relationships Use the terms consistently in your unit testing. It will also give your refactoring a road-map.
Identify the hot area Start from the hot area will be most cost-efficient Example Through SVN log Along with the new work and bug fixing
Bottom-up? Have some integration test first Then, One practical approach is bottom-up Get a higher level of abstraction
Learn the function by testing it Characterization Test Start from the 1st (failing) exit Write your plan on a piece of paper
Make the legacy code testable Use safe refactoring techniques to change the legacy code without unit testing. Extract function If you are using C ‘Data injection’ to break the dependency on globals.