Logging, Debugging and JUnit - Relationship

Discussions

General J2EE: Logging, Debugging and JUnit - Relationship

  1. Logging, Debugging and JUnit - Relationship (4 messages)

    I learn log4j now. The author Ceki Gýlcý writes that logging replaces debugging.

    I can't believe that. Maybe it reduces debugging, but it doesn't replace it. What do you think about it?

    And where is the borderline between logging, debugging and JUnit-testing? When and for what purposes do I use logging, when debugging and when JUnit-testing? How can I avoid to do obsolete logging, debugging and JUnit-Testing? How are logging, debugging and JUnit tests related?

    Threaded Messages (4)

  2. Debuggers, Logging[ Go to top ]

    http://jakarta.apache.org/log4j/docs/manual.html

    {{


    Inserting log statements into code is a low-tech method for debugging it. It may also be the only way because debuggers are not always available or applicable. This is usually the case for multithreaded applications and distributed applications at large.

    Experience indicates that logging was an important component of the development cycle. It offeres several advantages. It provides precise context about a run of the application. Once inserted into the code, the generation of logging output requires no human intervention. Moreover, log output can be saved in persistent medium to be studied at a later time. In addition to its use in the development cycle, a sufficiently rich logging package can also be viewed as an auditing tool.

    As Brian W. Kernighan and Rob Pike put it in their truly excellent book "The Practice of Programming"

      As personal choice, we tend not to use debuggers beyond getting a
      stack trace or the value of a variable or two. One reason is that it
      is easy to get lost in details of complicated data structures and
      control flow; we find stepping through a program less productive
      than thinking harder and adding output statements and self-checking
      code at critical places. Clicking over statements takes longer than
      scanning the output of judiciously-placed displays. It takes less
      time to decide where to put print statements than to single-step to
      the critical section of code, even assuming we know where that
      is. More important, debugging statements stay with the program;
      debugging sessions are transient.


    }}
  3. Debuggers, Logging[ Go to top ]

    I have the printed book of that manual and read that piece of text. This didn't answer my questions. Infact it raised my questions.
  4. I think the answer to this depends on the specifics of your programming environment.

    I spent several years coding in Smalltalk. The nature of the Smalltalk development environments made it very easy to work with your code in a debugger. You could easily step through your code without getting lost, change variables on the fly and restart execution a couple steps back in the stack, or modify your code and restart a step or two back in the stack. Almost all of the logging statements that went in the code were intended for use when the application was deployed in production. I also used the Smalltalk unit testing framework which was later ported to Java as JUnit.

    The project I'm currently working on is a J2EE EJB project. EJBs are difficult to debug since you have to hook your debugger up to the container and debug the code while it's running inside the container. It's also difficult to debug the EJB deployment code each container vendor generates for their application server. In this type of environment, I find myself writing more logging statements that are intended as a development aid than I would if I were not coding EJBs.

    JUnit tests when coded thoughtfully reduce both the need for using a debugger and the need for writing logging statements. For example, it's fairly common to write logging statements that display the value of an attribute as code is being executed so the developer can verify the value of the attribute is correct at each step in the code. You could replace this type of debug level logging with a JUnit test or series of tests that assert the value of the attribute is a certain value at each step in the code. You wouldn't have to manually check the value of the attribute in the debugger or by looking at some log file. Some would even argue that JUnit can replace debugging and debug level logging.

    If I were working with POJOs and could run my code inside my IDE (and outside of the EJB container) I'd definitely use a debugger more.

    Log4j is a great logging tool and I have a copy of Ceki's book. However, I'd have to say that I rely more on JUnit during development than I rely on log4j for finding problems in my code.

    I would agree with you that logging does not replace debugging. How much you rely on each of the three techniques really boils down to your language and environment.
  5. Thanks for the answer Dion.

    Ceki Gülcü seems to be too negative about debugging. I mean, there is no such think like "Log Driven Development" or "Log first".