atom feed17 messages in com.googlegroups.testng-devRe: Proposal to change the logging in...
FromSent OnAttachments
Claude QuézelSep 29, 2006 6:08 pm 
PaulSep 30, 2006 6:08 am 
Claude QuézelSep 30, 2006 6:20 am 
Alexandru PopescuSep 30, 2006 6:47 am 
Claude QuézelSep 30, 2006 7:35 am 
Cédric Beust ♔Sep 30, 2006 8:40 am 
Alexandru PopescuSep 30, 2006 10:17 am 
Claude QuézelSep 30, 2006 10:27 am 
Claude QuézelSep 30, 2006 11:02 am 
Alexandru PopescuSep 30, 2006 11:11 am 
Alexandru PopescuSep 30, 2006 11:13 am 
Alexandru PopescuSep 30, 2006 11:18 am 
Claude QuézelSep 30, 2006 11:31 am 
Jesse KuhnertSep 30, 2006 11:33 am 
Claude QuézelSep 30, 2006 11:46 am 
Cédric Beust ♔Oct 1, 2006 9:10 am 
Alexandru PopescuOct 2, 2006 5:33 am 
Subject:Re: Proposal to change the logging in TestNG (déjà vue!)
From:Alexandru Popescu (the.@gmail.com)
Date:Sep 30, 2006 10:17:58 am
List:com.googlegroups.testng-dev

On 9/30/06, Claude Quézel <cque@gmail.com> wrote:

Alexandru Popescu wrote:

I don't think this approach is really fitting TestNG, because our current logging is mainly meant for debugging purposes, and for different level of details. These are somehow crosscutting logging: the level 2 for example is used to provide a little more output about what is run, level 3 is for debugging why something is run, etc. These points are spread across the whole source base, and thus using the above logging doesn't help too much.

./alex

There are two parameters: 1) The logging level (or detail). 2) Which portion of the code we are interested in.

What is potentially logged for a certain loggin level is determined by the coder using the logging API: LOGGER.debug(), LOGGER.info(), ... LOGER.critical(). What is actually logged is chosen by the user in log4tesng configuration. The portion of the code we are interested in is set by the user in log4tesng configuration. for example if I'm interested in what's going on in the TestNG class I would configure log4testng like:

log4testng.logger.org.testng.TestNG=DEBUG

The -log on the command line logging strategy corresponds to setting a logging level to the root logger. i.e. the top of the logger hierarchy. So basically it's an application wide contition. We log "all over" at various levels of details. For this situation, log4testng (or any logging framework) is more flexible as it alows you to select specific parts of the code you are interested in.

log4testng.logger.rootLogger= ...

The verbose option in the suite.xml file is different as it enables logging for a portion of an execution (the suite or the test) (portion of code and portion in time). There is no corresponding features in log4j or J2SE Logging. This is more like changing the logging level of all loggers that will be reached by a specific thread or groups of threads for a certain time. This could easily be added to log4testng using thread local and an on/off nethod. One way to simulate this with loggers, imperfectly of course, would be to dynamically change the root logger's logging level when the suite or the test begins executions. I'm not so sure that this is essential for debugging purposes as the general logging strategy used by loggers provides all the same information (just a little more in some situation).

Basically, i don't think this type of logging is so far from our needs.

Thanks for the detailed explanation Claude, but I am fairly familiar with logging frameworks. And I am still convinced that this kind of logging is not enough:

1/ debug -> fatal do not correspond to 1-10; plus it would be pretty unusual to use log.fatal("10 tests run, 10 success, 0 failures, 0 skipped"); when in fact I want to say:

log(1, "10 tests run, 10 success, .... ");

2/ as I already said: TestNG logs on a specific level crosscutting the whole sourcebase: for example determining if a method is a valid @Test is decided in quite a few places: XmlMethodSelector, TestRunner, Invoker. How can this be achieved with the logger?

Plus, for example, TestRunner logs information about what methods are run (level 2), why methods are run (level 3), how methods are run (level 4). I don't see a way the logger is able to do this and also work with the previous 2 requirements.

./alex