Breaking dependencies when you can't make changes to other files?

Question

I'm doing some stealth agile development on a project. The lead programmer sees unit testing, refactoring, etc as a waste of resources and there is no way to convince him otherwise. His philosophy is "If it ain't broke don't fix it" and I understand his point of view. He's been working on the project for over a decade and knows the code inside and out. I'm not looking to debate development practices.

I'm new to the project and I've been tasked with adding a new feature. I've worked on legacy projects before and used agile development practices with good result but those teams were more receptive to the idea and weren't afraid of making changes to code.

I've been told I can use whatever development methodology I want but I have to limit my changes to only those necessary to add the feature. I'm using tdd for the new classes I'm writing but I keep running into road blocks caused by the liberal use of global variables and the high coupling in the classes I need to interact with. Normally I'd start extracting interfaces for these classes and make their dependence on the global variables explicit by injecting them as constructor arguments or public properties.

I could argue that the changes are necessary but considering the lead never had to make them I doubt he would see it my way. What techniques can I use to break these dependencies without ruffling the lead developer's feathers?

I've made some headway using:

• Extract Interface (for the new classes I'm creating)
• Extend and override the wayward classes with test stubs. (luckily most methods are public virtual)

But these two can only get me so far.

Note

Part of the lead's responsibilities is to review code submissions. He would likely interpret an anti-corruption layer as excessive at best and an insult at worst.

Answer 1

You should create an anticorruption layer, where you basically keep a layer between you and the "expert's" code using wrapper classes. This will be the price of dealing with such nonsense.

There are also some mocking frameworks that allow you to deal with not having to change existing code, but these would probably get you into more trouble politically than simple wrapper classes.

Answer 2

In such a case, an anti corruption layer might work, though you have to be careful as too many of these lead to pretty horrible results.

With such a layer, you could threat the rest of the system as you would threat external resources.