That's true - but then it should be turned on when you are looking for
said bug. If things are running fine, keep the logging off.
geir
Stepan Mishura wrote:
I'd like to add that logging may help when you are not able to reproduce a
bug.
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 1/24/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
On 1/24/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Mikhail Loenko wrote:
Hello
We have figured out that one of approcahes that was earlier dicussed
and that
I originally opposed would work for us.
That is: get PerformanceTest class out of there and replace log() with
calls
to java.util.logging.Logger.
Please let me know what you think.
What are you logging?
Normally any information that would be useful to easily detect
the reason of failure. A good test explains why it failed, the best test
submits a bug report and provides a patch, the worst test
just complains that it failed.
I would not wish to debug just to figure out that the reason of failures
is
that I've forgot to include something to classpath or there is another
config problem
Nobody is going to search log files looking for success/failure
messages.
Agreed
If the test passes, then all is fine; if it does not pass then it should
inform the framework (i.e. a failing assertion or an explicit call to
fail()). At that point JUnit will give you a cause of failure, and if
fail() is not always convinient, for example, how would you print
stack trace to fail()? Meanwhile stacktrace is most often enough
to find what the problems are and sort them out.
Thanks,
Mikhail
that is not enough you debug it with a debugger not println's.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
