This book is extremely overrated because the whole thing can be summed up in two bullet points:

* write your new code somewhere outside the main solution and call it from the old solution

* automated tests are pretty cool and you should write these whenever possible

I found the book to be close to useless when I was working with actual legacy code. How do I write an unit test for an application that has an embedded Visual Basic script support with dozens of scripts that are thousands of lines long? The book does not answer this question at all because the author assumed I have the luxury of working with Java or an another language that supports the object-oriented paradigm and can be endlessly extended with no limitations whatsoever.

>How do I write an unit test for an application that has an embedded Visual Basic script support with dozens of scripts that are thousands of lines long? The book does not answer this question at all because the author assumed I have the luxury of working with Java or an another language that supports the object-oriented paradigm and can be endlessly extended with no limitations whatsoever.

Why does the idea of identifying seams not apply to Visual Basic Script?

I've never worked with Visual Basic Script, but I don't see why Feathers' strategy wouldn't apply.

I agree that modernizing legacy code is easier in languages like Java, but I don't think it's strictly necessary. I've used Feathers' techniques for testing C code.