should I avoid static method as it's hard for testing? [closed]

Question

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.

Closed 9 years ago.

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?

Answer 1

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.