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!
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.
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.
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.
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?
6 comments
[ 0.20 ms ] story [ 25.4 ms ] threadBut 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.
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?