So regards logging from SO and other sites on the Internet the best response seems to be:
void DoSomething() {
Logger.Log("Doing something!");
// Code...
}
Now generally you’d avoid static methods but in the case of logging (a special case) this is the easiest and cleaniest route. Within the static class you can easily inject an instance via a config file/framework to give you the same effect as DI.
My problem comes from a unit testing perspective.
In the example code above imagine the point of DoSomething() was to add two numbers together. I’d write my unit tests for this fine. What about the logging?
Would I write a unit test for the logging (yet use a mock instance for the logger itself)? I know if this was the case I would have to write an integration test to prove the logger actually wrote to a log file but I’m not sure.
Following Test Driven Development (which I do) the unit test would be required for me to dictate the interface no?
Any advice?
Personally, I practice TDD/BDD pretty religiously and I almost never test logging. With some exceptions logging is either a developer convenience or a usability factor, not part of the method’s core specification. It also tends to have a MUCH higher rate of change than the actual semantics of the method, so you wind up breaking tests just because you added some more informational logging.
It’s probably worthwhile to have some tests that simply exercise the logging subsystem, but for most apps I wouldn’t test that each class uses the log in a particular way.