Comments on: Static Methods are Death to Testability

By: Puneet Monga

Puneet Monga — Tue, 08 Jun 2010 12:26:10 +0000

Agreed with the following points in your blog:
1) Its procedural code
2) Nothing to wire
3) They have access to the global state of the application
4) It cannot be mocked.

However, please note that these points serve as “donts” while coding a static method.

1) Its procedural code : Not all the code always belong to some or the other class.
2) Nothing to wire: If you have something to wire inside the static method, it means that its high time that you revisit the implementation of this static method.
3) They have access to the global state of the application: High time again to revisit and redefine your static method
4) It cannot be mocked: If static method has to be mocked, its high time again to revisit and redefine your static method.

Purpose of static methods is to write more of utility kind of methods that takes an input, returns an output provided that it doesn’t remember the state and doesn’t depend on any external components. If you break these rules, that’s a coding problem and not to blame static methods for the same.

Static methods that puts testability at risks means that static methods were not written they were supposed to be.

That’s also the case for instance (non-static) methods as well. If one is not aware of how to write non-static methods properly, then too it can put testability at risk.

By: dotnetdave

dotnetdave — Mon, 26 Apr 2010 23:03:14 +0000

Extension Methods are wonderful for customising your c# dev practices. So long as you don’t mind wrapping your literal numbers in brackets, why not just use something like the following?

(-5).Abs()

public static int Abs(this int someNumber)
{
return Math.Abs(someNumber);
}

By: misko

misko — Tue, 09 Mar 2010 04:29:26 +0000

Hi Monoj,

My understanding of encapsulation is that only the object methods should interact with the state of the object. This is why a service object which has getters/setters breaks encapsulation. With regard to constructor I don’t think it break encapsulation, as you are not allowed to modify the state of the object, you only need to provide the state/dependencies on creation. In addition the callee is does not know how to create the dependency, it asks for it likewise.

Here is some more discussion I found online
http://stackoverflow.com/questions/1005473/must-dependency-injection-come-at-the-expense-of-encapsulation

By: manoj

manoj — Mon, 08 Mar 2010 11:41:42 +0000

Hi,
with regards to this and also the article about Singletons, it seems to me that you are talking in general about code that has dependecy pull. e.g.
a Class X has a process() method that goes like {
y = new YImpl();
y.doIt();
}
So you have a problem with testing this method since calling process() is always calling YImpl, and this cannot be changed with some other implementation. So YImpl should have been explicitly passed to process() ?

But as we pass more and more parameters, does it not break encapsulation ? There could be problems related with improper use. So somebody may be able to pass an incorrect instance of creditcardprocessor that bypasses logging/auth ?

By: misko

misko — Sat, 02 Jan 2010 20:52:26 +0000

The performance of using static vs instance method/variables is next to insignificant, so I would not use that as an argument.

By: Helltime for January 1 « I Built His Cage

Helltime for January 1 « I Built His Cage — Sat, 02 Jan 2010 01:34:53 +0000

[...] The gist of the post is to use static members whenever you can for values that you know won’t change. There is a potentially significant performance boost, but I fear advice like this will lead monkeys to apply staticity to areas where it is inappropriate and doom their testing efforts. [...]

By: Se hace camino al andar… » Blog Archive » Métodos estáticos y pruebas unitarias

Sun, 13 Dec 2009 22:54:20 +0000

[...] para obtener información de contexto y, sobre todo, de la plataforma. Y me viene al pelo el reciente artículo de Misko Hevery donde explica por qué los métodos estáticos son tan malos para las pruebas y delatan diseños [...]

By: Principles, Patterns, and Practices of Mediocre Programming : Steve Smith's Blog

Principles, Patterns, and Practices of Mediocre Programming : Steve Smith's Blog — Thu, 08 Oct 2009 18:44:01 +0000

[...] Static Methods are Death to Testability [...]

By: misko

misko — Wed, 02 Sep 2009 15:43:20 +0000

@Heiko,

I know few functional languages, and while I am nowhere as versed in them nor have as much experience in OO, I do know, that many things are still the same. Instead of injecting classes you need to inject functions, and testability is still something you need to think about.

But these blog posts are not about functional languages! These blog posts are about OO languages.

– Misko

By: Heiko

Heiko — Wed, 02 Sep 2009 14:49:56 +0000

Learn a functional language. Then you certainly will rewrite your post.