4 ms·

> Start adding unit tests around the legacy code Adding unit tests is often hard to do with legacy code because it wasn't designed to be granularly testable. I

> Start adding unit tests around the legacy code Adding unit tests is often hard to do with legacy code because it wasn't designed to be granularly testable. It is often better to figure out what interface that code provides and then add tests of that layer of abstraction. Then, you can refactor more safely so the code is unit-testable.

retbull 11y ago
ugh I had to do this recently. Per the original author "Writing a unit test involves creating a mock db, http client, http server, and several data objects"... I hurt when I had to write tests for that. It isn't that much better now but I did improve the data objects so they have builders which have sensible defaults.
- mjnaus 11y ago
  There are other ways of testing which are more suitable, at least until you get your code base to the point where unit tests can more easily be applied. Smoke tests, functional tests, integration tests, QA, are workable solutions to build an initial testing harness around legacy code.
ngoede 11y ago
I agree adding testings around legacy code is very difficult. One thing I found very helpful when I first started working in a large mostly untested codebase was "Working Effectively with Legacy Code" by Michael Feathers. It is really nice because its chapters are arranged around specific problems you will encounter wrapping existing code in tests so you can easily find the write chapter via the table of contents.
kyllo 11y ago
Adding unit tests is often hard to do with legacy code Especially if you have to write them in COBOL.
- Rexxar 11y ago
  Apparently there is something called "zUnit" for COBOL.
mannykannot 11y ago
What I noticed about this article was what was not suggested. Is analysis - reading and thinking about what code does - no longer considered feasible? When I used to have to deal with this sort of thing, it seemed that a combination of analysis and testing, with much of the testing being open-box and with the liberal use of assertions, was most effective.
- MaulingMonkey 11y ago
  > Is analysis - reading and thinking about what code does - no longer considered feasible? "Not shipping" and "ensuing mass layoffs followed by bankruptcy" are still considered feasible. I kid, I kid. A few thousand lines of code in isolation? Piece of cake, I can grok it within the hour. Ten lines of WTF intertwined within a multi-million LOC codebase making judicious abuse of reflection, TLAs, and layer upon layer of misnamed abstractions which do something subtly different from what you expected - using three technology stacks spanning three decades of changing idioms and trends in software development - written in a 'mission critical' culture where bugs are intentionally kept as backwards comparability features? Three people will claim to understand the code well enough to make changes within a week: The rookie, the madman, and the asshole who wrote it. If you're lucky, none of them still work there - based on the number of bugs increasing when "fixes" are applied, it's clear none of them do, or ever did. Priding myself on being only half mad, I will claim to understand 5 out of 10 of those lines within a week. If I'm lucky, they'll even be the 5 lines I need to modify for your feature request. Based on my vague understanding of the few tens of thousands of lines of code these 5 lines interact with, I can assure you I am half certain[1] that I probably didn't break anything [2]. [1] Read: Half uncertain [2] Read: I'm assuming our QA team are not mere mortals, but are gods, and thus have at least a 50% chance of catching any bugs I introduced.
  - andrewaylett 11y ago
    I've worked with that QA team. They really were that good, but unfortunately they really were that necessary. The real difficulty is that you've no way of knowing whether the WTF you're looking at is inappropriately placed (and completely undocumented) business logic, an actual bug or a seriously hacky workaround for a bug in a completely different area of the code. If a bug, it may well be itself worked around by a seriously hacky fix somewhere completely different, which will break horribly if you fix the issue here. If it's a fix or especially if it's business logic then then it's even odds that it's not required any more.
YZF 11y ago
Right... So add system/integration tests. After all what you really care about is the behaviour of the system. It can be counter-productive to unit test pieces of legacy code because you may end up refactoring things at a higher level and breaking all your unit tests. If it's clear that a piece of the legacy system stands on its own as a "unit" and has reasonable interfaces then by all means add unit tests to that. The biggest value though IMO in a "legacy" system is to add system level tests. Those are often easier to put in than unit tests, will catch problems involving multiple components, and will teach you about how the system is supposed to behave.
- kartan 11y ago
  > add system/integration tests. For me this is clearly the way to go. If you add unit tests to a bad designed interface you are only making it more difficult to fix. Now you don't only need to change the interface but also the tests increasing your technical debt. System tests are the best cost/value tests. You only add unit testing to stable code that is not going to change often. System tests cover the same code that the unit tests. Its only disadvantage is that - maybe - it will take more time to know what is failing when something fails as they cover a broader amount of code.

retbull 11y ago

ugh I had to do this recently. Per the original author "Writing a unit test involves creating a mock db, http client, http server, and several data objects"... I hurt when I had to write tests for that. It isn't that much better now but I did improve the data objects so they have builders which have sensible defaults.

mjnaus 11y ago
There are other ways of testing which are more suitable, at least until you get your code base to the point where unit tests can more easily be applied. Smoke tests, functional tests, integration tests, QA, are workable solutions to build an initial testing harness around legacy code.

ngoede 11y ago

I agree adding testings around legacy code is very difficult. One thing I found very helpful when I first started working in a large mostly untested codebase was "Working Effectively with Legacy Code" by Michael Feathers. It is really nice because its chapters are arranged around specific problems you will encounter wrapping existing code in tests so you can easily find the write chapter via the table of contents.

kyllo 11y ago

Adding unit tests is often hard to do with legacy code Especially if you have to write them in COBOL.

Rexxar 11y ago
Apparently there is something called "zUnit" for COBOL.

mannykannot 11y ago

What I noticed about this article was what was not suggested. Is analysis - reading and thinking about what code does - no longer considered feasible? When I used to have to deal with this sort of thing, it seemed that a combination of analysis and testing, with much of the testing being open-box and with the liberal use of assertions, was most effective.

MaulingMonkey 11y ago
> Is analysis - reading and thinking about what code does - no longer considered feasible? "Not shipping" and "ensuing mass layoffs followed by bankruptcy" are still considered feasible. I kid, I kid. A few thousand lines of code in isolation? Piece of cake, I can grok it within the hour. Ten lines of WTF intertwined within a multi-million LOC codebase making judicious abuse of reflection, TLAs, and layer upon layer of misnamed abstractions which do something subtly different from what you expected - using three technology stacks spanning three decades of changing idioms and trends in software development - written in a 'mission critical' culture where bugs are intentionally kept as backwards comparability features? Three people will claim to understand the code well enough to make changes within a week: The rookie, the madman, and the asshole who wrote it. If you're lucky, none of them still work there - based on the number of bugs increasing when "fixes" are applied, it's clear none of them do, or ever did. Priding myself on being only half mad, I will claim to understand 5 out of 10 of those lines within a week. If I'm lucky, they'll even be the 5 lines I need to modify for your feature request. Based on my vague understanding of the few tens of thousands of lines of code these 5 lines interact with, I can assure you I am half certain[1] that I probably didn't break anything [2]. [1] Read: Half uncertain [2] Read: I'm assuming our QA team are not mere mortals, but are gods, and thus have at least a 50% chance of catching any bugs I introduced.
- andrewaylett 11y ago
  I've worked with that QA team. They really were that good, but unfortunately they really were that necessary. The real difficulty is that you've no way of knowing whether the WTF you're looking at is inappropriately placed (and completely undocumented) business logic, an actual bug or a seriously hacky workaround for a bug in a completely different area of the code. If a bug, it may well be itself worked around by a seriously hacky fix somewhere completely different, which will break horribly if you fix the issue here. If it's a fix or especially if it's business logic then then it's even odds that it's not required any more.

YZF 11y ago

Right... So add system/integration tests. After all what you really care about is the behaviour of the system. It can be counter-productive to unit test pieces of legacy code because you may end up refactoring things at a higher level and breaking all your unit tests. If it's clear that a piece of the legacy system stands on its own as a "unit" and has reasonable interfaces then by all means add unit tests to that. The biggest value though IMO in a "legacy" system is to add system level tests. Those are often easier to put in than unit tests, will catch problems involving multiple components, and will teach you about how the system is supposed to behave.

kartan 11y ago
> add system/integration tests. For me this is clearly the way to go. If you add unit tests to a bad designed interface you are only making it more difficult to fix. Now you don't only need to change the interface but also the tests increasing your technical debt. System tests are the best cost/value tests. You only add unit testing to stable code that is not going to change often. System tests cover the same code that the unit tests. Its only disadvantage is that - maybe - it will take more time to know what is failing when something fails as they cover a broader amount of code.