Recently I got asked by a co-worker on how he would go about testing the invocation of a static method in some legacy codebase. Not as easy as one might guess initially. We went for the Subclass and Override Technique. Of course a conversation on whether
static should be used at all ensues…
The discussion on
static has been had multiple times all over the internet. The answer is usually the following:
There are times when using static is fine and times when it’s not.
Thus were stuck with the usual
It depends answer.
[…] the issue I have is that static methods are acceptable in weird conditions which I and you understand. Than [sic] a new developer shows up and does not understand the complex nature of static methods testability and thinks stitic [sic] methods are ok. It creates a slippery slope in which he can modify it and what once was an testable static method becomes untestable. I don’t want to have to explain this to people. There is zero cost to have that private method non-static, and I don’t want to have a debate with people when there are ok times. It is much easier to say no static methods allowed since what you are loosing is so little, and what you are preventing from happening is so much. An excellent trade.
I agree. There are usually way more important things to discuss in a team than whether or not to use some controversial features of Java.