harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Loenko <mloe...@gmail.com>
Subject Re: [classlib] Unit and performance testing
Date Wed, 25 Jan 2006 07:49:10 GMT
OK, I'll review the logs and remove those ones that certainly unnecessary.

Then we'll see what are the remaining ones and what to do with them.

Thanks,
Mikhail.


On 1/24/06, Geir Magnusson Jr <geir@pobox.com> wrote:
> 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 <mloenko@gmail.com> wrote:
> >> On 1/24/06, Tim Ellison <t.p.ellison@gmail.com> 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 (t.p.ellison@gmail.com)
> >>> IBM Java technology centre, UK.
> >>>
> >
> >
> >
> > --
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
> >
>

Mime
View raw message