Unit Testing

Are Static Methods an Anti-Pattern?

Is using the Static keyword on class members and methods an anti-pattern? I think so and hopefully this post will get you thinking about it. Primarily I see Static abused when programmers do not want to go through the work of instantiating a class. This is in circumstances in which instantiation is not strictly necessary. The problem with Static members is that they get in the way of approaches such as Inversion of Control and Test Driven development.

Why Unit Testing Constructors and Properties is Necessary

I have come across developers in the past that see little value in Unit Testing things like Constructors and Property getters/setters. Some devs see these as fruitless exercises just to bump code coverage numbers. The point of some is that setters/getters don’t really do anything and that complex code does not belong in constructors. I agree, this should be the case but not always true. I frequently run across abuse on constructors and properties. We also can not guarantee that ongoing maintenance from new developers or other teams (in big software houses) will follow best practices. Of course the same argument can be said about maintaining Unit Tests, but if you have made it this far I am assuming we are an advocates of TDD and do not need to defend it.

So, I offer a couple of examples of why Unit Testing properties and constructors is necessary. These come from real-world scenarios and clients but have been renamed to protect the innocent. Both examples come from production code which is serving up millions of hits a day.