3 ms·

i'm working on legacy huge spagetty code with no option to write effective integration tests, testing that my method retuns some correct string/int etc will do

by Tomer 16y ago

i'm working on legacy huge spagetty code with no option to write effective integration tests, testing that my method retuns some correct string/int etc will do me nothing, the whole system is huge with many integration points and no infra for writing integration tests and no time to do it. what should i do? (I love TDD, tests in general).

timclark 16y ago
You can make things better if you are prepared to make the effort, the politics can sometimes be harder than the technical work. It might be worth seeking out a copy of Working Effectively with Legacy Code by Michael C Feathers.
- Tomer 16y ago
  thanks!!
philbo 16y ago
I've been in a similar situation in the past. The approach I took was to work gradually and try to clean the most heavily-used mess bit-by-bit, under the radar if necessary. For instance, take the particular long, messy function that you happen to be working with right now, then write a bunch of tests for that function. Test that invariants are maintained, bad arguments or pre-conditions are handled, post-conditions are honoured and so on. You don't even have to know whether what you are testing is correct behaviour at this point. Just get as much test coverage as you practically are able to. Then you can start TDDing smaller functions that are made up of bits and pieces from the big, ugly beast-function. You can develop and test these in complete isolation from the running code. Finally you start replacing bits of the ugly beast with calls to your new clean functions, ensuring that you don't break any of those tests you wrote at the start. Over a period of time, you will gradually build up a set of unit tests for the most important parts of the system and you will hopefully gain enough confidence to refactor it into something more maintainable. At least, that's the theory, anyway. :) I would also strongly recommend reading Michael Feathers' excellent book, Working Effectively With Legacy Code (ISBN: 978-0-13-117705-5). It is the bible for this kind of work.
gte910h 16y ago
This is actually the type of system (especially if it's very rough code quality wise in many places) I think regression tests are very useful (tests to make sure the system doesn't change function). A book called "Working effectively with legacy code" by Feathers is great for instrumenting and regression testing old code bases then changing them without breaking them. Non-aff link http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=sr_1_1?ie=UTF8&qid=1288192392&sr=8-1 http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...
Dylanlacey 16y ago
You start. That's all. Just... start. Is one unit test doing anything? Yes. Absolutely. It's giving you 1 more unit test then you had to begin with. Once you have a test, you can write another test. You can refactor a method (And write tests). You can then refactor the calling methods. And so on. "It will be a mammoth task" is only a good reason not to do something when it's either discardable in the near future (And not "When we start on V2!"), or if it's the canonical 9-woman-1-baby situation. If partial improvements give value, do them.

by Tomer 16y ago

timclark 16y ago

You can make things better if you are prepared to make the effort, the politics can sometimes be harder than the technical work. It might be worth seeking out a copy of Working Effectively with Legacy Code by Michael C Feathers.

Tomer 16y ago
thanks!!

philbo 16y ago

I've been in a similar situation in the past. The approach I took was to work gradually and try to clean the most heavily-used mess bit-by-bit, under the radar if necessary. For instance, take the particular long, messy function that you happen to be working with right now, then write a bunch of tests for that function. Test that invariants are maintained, bad arguments or pre-conditions are handled, post-conditions are honoured and so on. You don't even have to know whether what you are testing is correct behaviour at this point. Just get as much test coverage as you practically are able to. Then you can start TDDing smaller functions that are made up of bits and pieces from the big, ugly beast-function. You can develop and test these in complete isolation from the running code. Finally you start replacing bits of the ugly beast with calls to your new clean functions, ensuring that you don't break any of those tests you wrote at the start. Over a period of time, you will gradually build up a set of unit tests for the most important parts of the system and you will hopefully gain enough confidence to refactor it into something more maintainable. At least, that's the theory, anyway. :) I would also strongly recommend reading Michael Feathers' excellent book, Working Effectively With Legacy Code (ISBN: 978-0-13-117705-5). It is the bible for this kind of work.

gte910h 16y ago

This is actually the type of system (especially if it's very rough code quality wise in many places) I think regression tests are very useful (tests to make sure the system doesn't change function). A book called "Working effectively with legacy code" by Feathers is great for instrumenting and regression testing old code bases then changing them without breaking them. Non-aff link http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=sr_1_1?ie=UTF8&qid=1288192392&sr=8-1 http://www.amazon.com/Working-Effectively-Legacy-Michael-Fea...

Dylanlacey 16y ago

You start. That's all. Just... start. Is one unit test doing anything? Yes. Absolutely. It's giving you 1 more unit test then you had to begin with. Once you have a test, you can write another test. You can refactor a method (And write tests). You can then refactor the calling methods. And so on. "It will be a mammoth task" is only a good reason not to do something when it's either discardable in the near future (And not "When we start on V2!"), or if it's the canonical 9-woman-1-baby situation. If partial improvements give value, do them.