-3

I read the book Working effectivly with Legacy code.

I understand the technics to break dependencies in Legacy code

But I want to understand how to avoid these dependencies for the first time:

1- Regarding static methods:

I understand Introduce Instance Delegator

But does it mean we should avoid static methods at all?

(when it not just a Macro for some piece of code.

Meaning it has some real logic and it's instance independant?)

2- Global variable

I understand Introduce Static Setter,

but again - should we avoid Singelton at all?

Elad Benda
  • 35,076
  • 87
  • 265
  • 471
  • Although i do not fully understand your question I'd answer to not avoid those things at all. Why do you consider static methods hard to test? – Luis Filipe Apr 13 '12 at 10:48
  • If you 'want' to work with legacy code, there's no avoiding at all, that's why it's called **legacy** code... Now I'm not the biggest C# fanatic, far from it. But I wouldn't classify C# as being legacy code (yet). – Elias Van Ootegem Apr 13 '12 at 10:48
  • @Luis Filipe it's hard to mock this methods during testing (as extract and override) – Elad Benda Apr 13 '12 at 10:55

1 Answers1

0

The critisicm of static methods in the world of unit testing traditionally is the difficulting in mocking them out. I have never agreed with that as a reason for avoiding static methods (and in anticipation of those who disagree, not everyone has the luxury of using an IOC container).

There are tools that will mock static classes, such as JustMock.

Another, dirtier approach for mocking singletons is to have the singleton return an interface and mock out the instance on the singleton during unit testing using a private accesssor or straight reflection.

roken
  • 3,946
  • 1
  • 19
  • 32