Unit Testing – Static Methods and Testability

(Using Java terminology): Static methods can be associated with static members (members of the class object). If the methods don't access static members (nor IO resources or anything else that could change state), of if those members are final primitives or immutable objects (essentially constants), then such static methods could be called functions, but in general, because they potentially could access the class object's members, they're usually called static methods.

In order to count as a function, a method must be independent of any state; it must not cause any side effects nor be affected by any side effects. When called with specific parameters, it must always return the same result. Otherwise it's not a pure function.

That is, the following area is a function:

class MyClass {
    static final double pi = 3.14;
    static double area(double r) {
        return pi * r * r;
    }
}

while the following getCallCount is not a function:

class MyClass {
    static int callCount = 0;
    static int getCallCount {
        return ++callCount;
    }
}

In general, mutable (non-final) static members should be used with caution - someone would say that they should not be used at all - because they make a global state to the program, which likely turns out to be a bad design choice in the long run. There are exceptions, but be careful...

You don't even need static members to make static non-functions: System.nanoTime() is definitely not a pure function (because it returns different value on successive calls), even though it only accesses the computer's clock, not any static members.

Confusingly enough, you could also make non-static pure functions:

class MyClass {
    final double pi = 3.14;
    double area(double r) {
        return pi * r * r;
    }
}

Now, although not static any more, area is still a pure function: it doesn't touch anything that could change. The fact that you would have to create an instance of MyClass to access area doesn't reduce its "functionness". Indeed, one could argue that this kind of pure functions should always be made static.

Those aren't static methods they are on the prototype. Instances of foo would be able to call static methods by just doing this.statics.method. True statics would be applied to just foo itself. It is also cleaner than putting logic in the constructor to handle statics.

function foo() {

}

foo.statics = {

}

console.log(new foo().statics)
//undefined
console.log(foo.statics)
// {}

The framework that we write in allows statics this way, it is a nice way to keep enums and constants. It also gets around problems that happen when instance sharing is not needed and non primatives are placed on prototype, which for some reason happens all of the time on SO. Problems arise during inheritance though since static methods defined this way won't be inherited. The inheritance problem mostly arises after due to parent classes having methods that do this.class.statics.staticFn if the class is inherited from those methods won't work but that can easily be fixed.

update

Having to invoke a function to get at the statics and having logic in the constructor to have it handle and know about it having statics is bad in my opinion. The user has to know that the statics need to be accesses by invoking a function and the constructor needs to know that it has statics and to handle the case where the new operator is not used.

Problems can arise when instances don't know that they are modifying statics. In this case lets replace the name statics with config.

function foo(){
   if ( !foo.prototype.config ){
       foo.prototype.config = {
           a: 1,
           b: 2
       }
   }
   if ( !(this instanceof foo) ){
        return foo.prototype.config;
   }
}

foo.prototype.foobar = function() {
  this.config.a = 5;
}


foo()
>Object {a: 1, b: 2}
new foo().foobar();
foo();
> Object {a: 5, b:2}