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
