Comments on: Static Methods are Death to Testability

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.

By: misko

misko — Tue, 11 Aug 2009 15:21:58 +0000

@Mr Panda,

I am totally serious! The thing is that Math.abs() is easy to test and it is static, but it is also a leaf of your call graph, and should really be -5.abs() anyway. It is easy to test, but not because it is static, but because it is leaf. The farther your static method is from the leaf of the call graph the harder it will be to test. Look at main method, it is essentially impossible to test anything form it, and it is static. Static methods cannot be overridden, and there lies the problem. Just because some static methods are easy to test does not imply that all static methods are easy to test.

By: Mr Panda

Mr Panda — Tue, 11 Aug 2009 11:16:47 +0000

To the author: you can’t be serious. Free functions are probably the most unit-testable constructs there are.

(Presuming they’re side effect free – and only a lunatic would routinely write free-functions that modify global state).