If you think unit testing might be a better solution, please stop now! In just a few words, I hate unit testing, I’ve never done it and I don’t think I ever will, unless the application I’m working on falls into one of those tiny, small and microscopic categories where unit testing actually makes sense. Writing code that validates other code that most likely will never change (at least most of it) just doesn’t make sense to me. Furthermore, in most web based applications the result of a test is actually something being displayed or rendered in a browser, so it’s much easier to just do the testing while you develop the application: write code, save, go to browser and press F5, check result and so on… quite easy!

Logging on the other hand is something I find truly useful. Not so much for testing, but for maintenance and debugging at a later stage. Once your application is set free into the wild, the real testing begins: scenarios you didn’t even thought were possible will start showing up and inevitably some bugs will surface. At this stage, it’s imperative and absolutely necessary for you to be able to  track down what is happening with your application.

I usually log almost everything. I’m using a logging system on 5 levels (below) meant to provide every bit of information about what the application is doing at any stage.

Level 1 – Errors
When an error message is generated, it means the application or a specific piece of code cannot perform the action it’s supposed to do and cannot recover or find alternative solutions to complete the action.

Level 2 – Warnings
Warnings are less severe error messages if you will. It means the application cannot perform a certain action, but could use an alternative solution. It could also mean that some features of the application will be disabled, but overall the application is still able to perform the action is supposed to perform.

Level 3 – Info Messages
Info messages are generated whenever something non-deterministic is happening. For example, the user pressed a button or an e-mail was received.

Level 4 – Debug Messages
Debug messages are generated whenever something deterministic is happening or as additional messages for Level 3 above. For example, if you have a timer to perform some action every 20 seconds, you might want to generate debug messages.

Level 5 – Trace Messages
At this level I like to log everything. Basically, every function of my application will start with a trace message being generated. When this level is enabled, I can see every function call and the complete logic flow of the application. It’s very useful for tracking exactly where a problem occurs and could reduce debugging time a lot.

To conclude, I think logging could really save the day when it comes to debugging and maintaining a large scale application (think millions of requests/users per day). Bugs will inevitably appear and when they do, logging could make a really big difference.