I understand and I agree with the author points, specially looking to distance yourself from the dependencies these systems are usually entangled with, however:

>But the code examples are in Java and C++ and I do python/JavaScript/ruby/

The problem with real legacy code is that sometimes it's not even in those languages. It's VB.NET, COBOL, AS400, BASIC, FORTRAN...and these may not have a chance to "wrap around your class", or "think about all the ORM code that you use". None! I use none of that!. And I can't even call any tests because I can't extend a non existant class, there's no objects in here!.

The author also says:

>You need feedback. Automated feedback is the best. Thus, this is the first thing you need to do: write the tests.

I don't need automated feedback. I need to untangle this deep business layer that everything is wrapped around in a 40 years old codebase, with practically no documentation and having to modify one of the core systems of the company. Sometimes I can't even trust the feedback the program outputs. In this kind of scenarios where the code is so messy and limited by technical factors, the best approach I have found is to debug. And that's it. Follow the trail, find the "seam", and then start your kingdom in the little space you can. Because if you tell your boss that you are implementing Unit tests in a 40 years old codebase, the first question he is gonna hit you with is "Why?", and the article doesn't give any compelling argument to answer this.

Would you be so lucky if your legacy code was written in a well-known language. At a previous employer we had a big pile code in a “macro” language. It could interface with the main C++ code base. It was similar to assembly language in that it had no loops (just gotos) and register-like local variables (no custom names, just L0, L1, L2,…). The semantics were weird, something like unexpected pass-value-value versus pass-by-reference behavior when calling functions.

One customer required lengthy qualification processes when changing the software. But “configuration changes” had a lower bar and somehow these “macros” counted as config. So eventually all the interesting business logic and RPC processing end up in a giant macro file.

> the article doesn't give any compelling argument to answer this

Is "[w]hen code is not tested, how do you know you didn’t break anything?" not a compelling argument to your boss?

I read the book shortly after it came out, when I was working on an enormous system of legacy code. Unfortunately, I didn't find the book particularly helpful in terms of strategies for understanding or modifying legacy code. Yes, tests are a good thing, but I expected the book to provide a lot more.

I agree with the parent comment that it is useful to follow the "trail" through the code. It can be a big effort just to figure out how the pieces are connected. Figuring out the data structures and files is another important thing. Also, write documentation as you go; this will help others understand the big picture. If you can just jump in and start writing meaningful unit tests, your legacy system is kinda trivial :-)

Overall, there are people who view testing as a useful tool and people who view testing as an ideology. This book falls into the latter category.

I've skimmed the source material and it doesn't either except for the general advice of putting it all in some kind of conceptual box and slowly move parts to modern or better managed solutions as you try to reverse engineer it all. The underlying subtext was that it is all probably worse than you think and there isn't much good news... But "containment" in various forms is the direction forward mostly unfortunately.

> VB.NET

*laughs in VBA*

> And I can't even call any tests because I can't extend a non existant class, there's no objects in here!.

I'm gonna preach for the church of "away with unit tests": so what? You don't want to test code. Code is not what the user care about.

You want to test behavior. And for this you don't need to extend classes. You should not have to rewrite any code from your application. Like you say: write tests at the seam. Automate user inputs and checking outputs.

A good test suite should not need to be rewritten during refactoring. It should even allow you to change language or replace for an off-the-shelf solution you did not write. If a unit test suite does not allow that, unit tests are an impediment. And I don't care about the "test pyramid", like the IRL ones, it is just a relic; from an age when launching all your tests in parallel was unfathomable.