Comments on: Static Methods are Death to Testability

By: David Zentgraf

David Zentgraf — Thu, 05 Jan 2012 04:28:58 +0000

Static functions are only problematic if they have unseen dependencies (violate dependency injection principles) and are not idempotent (have state). It’s not even about being leaf methods, that’s just a recursive problem of my first sentence. Static methods are just functions. Functions are extremely easy to test if they’re idempotent. That’s the functional principle. Functions may call other functions as much as they like and it doesn’t change anything about their being idempotent, as long as the functions they call are also idempotent. You can have a long chain of function calls hanging off of your static method, if none of them have any state there’s no problem. That’s why Math.abs() is easy to test, because it adheres to these principles. In the background it may make a thousand calls to hundreds of different functions, you don’t need to care.

So your rant against static methods is really a straw man rant against non-idempotent global functions, hence global state. It has nothing to do with being static. Static functions are fine and useful in OOP.

By: MB

MB — Thu, 01 Dec 2011 05:15:48 +0000

http://code.google.com/p/powermock/

By: Static Methods: Time to Hit Rock Bottom | DaedTech

Static Methods: Time to Hit Rock Bottom | DaedTech — Tue, 01 Nov 2011 16:54:02 +0000

[...] They kill testability of code bases. Misko Hevery agrees. [...]

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 [...]