

Never Test Logging - xvirk
http://javax0.wordpress.com/2014/02/19/never-test-logging/

======
techsupporter
As someone who does Ops and support for a living, please test logging. I can't
tell you the number of times I've been told by a developer, "just send me the
logs," and no log was generated. Diagnostic logging should be a feature that
is considered in your application, especially one that will be put in front of
users. It will eventually break and will do so in a way that you didn't expect
and some overnight support person will be staring at "Generic Error 12: Error
11 didn't happen" with a screaming customer and no access to source.

------
jstanley
I don't think a good case is made here. If it doesn't need to be tested, that
implies it doesn't need to work. If it doesn't need to work, you don't need to
write it in the first place.

~~~
sphildreth
Preach it brother! Much truth in this.

------
sz4kerto
The author simplifies the problem a lot I think. He says there's is a quite
clear line between logging, alerting, etc. -- I say there isn't. What we did
recently in a quite critical system is we had a process to scrape the logfiles
-- essentially tailing them and looking for words like 'error', 'fail',
'exception', and so on (well, it was a bit more intelligent than that).
Whenever something smelly happened, then we received the log fragment in
email.

I hear the uproar, and I must say this was not our main alerting system. This
was the 2nd or 3rd fallback, because an alerting system has a lot of
dependencies and complexity, and it might fail in certain (unforeseen)
circumstances. Having an extra line of defense is nice, and there is a well-
tested, widely-used, reasonably simple way of communicating system state
(including problems): using a simple logging framework.

You could write something extremely simple low-level stuff for sending alerts
when the more sophisticated alerting system (with GUI, etc.) fails, but why
not use something that has been tested already?

------
rquantz
Now, I'm not saying you _should_ test logging, but I don't think the author
made much of a case here. You shouldn't test logging because it is a code
smell! If you are testing logging it's because it's not actually logging!

~~~
ams6110
You may be using a logging framework to satisfy some audit requirement, e.g.
to capture user login timestamps, or important transaction details. That
should be tested, since it's a feature of your software.

But even if you are just logging for behavior tracking/debug purposes, you
should at least verify that the logging framework is actually working,
otherwise it might not be there when you need it. If you're going to go
through the trouble to code something that's going to stay in the production
release, you should pretty much always at least do some basic smoke tests on
the feature.

