Static class/method/property in unit test, stop it or not

Question

Should a static class/method/property be used in a unit test development environment, given that there is no way to test it without introducing a wrapper that is again not testable?

Another scenario is that when the static members are used within the unit tested target, the static member cannot be mocked. Thus, you have to test the static members when the unit tested target is tested. You want to isolate it when the static member performs calculation.

Answer 1

Testing static method is no different than testing any other method. Having static method as a dependency inside another tested module raises problems (as it's been mentioned - you can't mock/stub it with free tools). But if the static method itself is unit tested you can simply treat it as working, reliable component.

Overall, there's nothing wrong (as in, it doesn't disrupt unit testing/TDD) with static methods when:

• it is simple, input-output method (all kinds of "calculate this given that")
• it is reliable, by what we mean it's either unit tested by you or comes from 3rd party source you consider reliable (eg. Math.Floor might be considered reliable - using it shouldn't raise "Look out, it's static!" warning; one might assume Microsoft does its job)

When static methods will cause problems and should be avoided? Basically only when they interact with/do something you cannot control (or mock):

• all kind of file system, database, network dependencies
• other (possibly more complex) static methods called from inside
• pretty much anything your mocking framework can't deal with on regular terms

Edit: two examples on when static method will make unit testing hard

1

public int ExtractSumFromReport(string reportPath) {      var reportFile = File.ReadAllText(reportPath);      // ... } 

How do you deal with File.ReadAllText? This will obviously go to file system to retrieve file content, which is major no-no when unit testing. This is example of static method with external dependency. To avoid that, you usually create wrapper around file system api or simply inject it as dependency/delegate.

2

public void SaveUser(User user) {     var session = SessionFactory.CreateSession();     // ... } 

What about this? Session is non-trivial dependency. Sure, it might come as ISession, but how do force SessionFactory to return mock? We can't. And we can't create easy to detemine session object either.

In cases like above, it's best to avoid static methods altogether.

Answer 2

Static methods CAN be unit tested. They can't be mocked (generally; there are some frameworks to do this like Moles.