I did consider using the Listener Config.

However that gives a problem for non-GUI runs, as there is no way to
configure the automatic listener (apart from via properties).

I guess there's no real need for a "Log Errors" checkbox to be added
to the Test Plan - it could just be done via a property, which I was
going to add anyway.
Indeed, do we need the Functional test checkbox?

I think the "Log Errors Only" checkbox is better as a separate item -
it defines when to log, the config defines what. Besides, moving it
might invalidate a lot of test plans. However, result data should only
be logged if the config says to do so.

S.
On 5/9/05, Michael Stover <[EMAIL PROTECTED]> wrote:
> That all sounds reasonable.  But, what about making the listener config
> do it all - ie, let users indicate what to save normally, what to save
> on errors etc.  I think that makes more sense than the ad-hoc checkbox
> on the TestPlan object approach.
> 
> -Mike
> 
> On Sun, 2005-05-08 at 11:53 +0100, sebb wrote:
> > Functional mode does not work currently in 2.1.
> >
> > Whilst looking into this, I noticed that "Log Errors only" does more
> > in 2.0 than just prevent successful results from being sent to the
> > visualizers - it also behaves like Functional Test mode for failed
> > results, in that the result Data is written to the test log.
> >
> > In 2.1 at present, "Log Errors only" behaves as I expected, i.e. it
> > suppresses successful results from appearing in the Listener (and its
> > log file) and it does not affect the data written to the log file.
> >
> > Seems to me it would be useful to extend the Test Plan GUI to add an
> > option to log Result Data for errors only. This would be useful for
> > checking why an assertion failed.
> > It would also be useful to add an equivalent property so the mode
> > could be set from the command line.
> >
> > ==
> >
> > I'd also like to suggest a change in the way Functional mode is implemented:
> >
> > At the moment, Functional Test mode is stored as a property by
> > TestPlan, and ResultCollector then stores it as a static variable.
> >
> > There will only ever be one Test Plan class in a Test Plan, so it
> > would be easy to add static methods to it to return the current
> > settings for Functional Test Mode (and my proposed Error Result Data
> > mode). This would make it easier to check (at present the setting is
> > copied to the ResultCollector class by scanning the classes.)
> >
> > [The TestPlan.FUNCTIONAL_MODE property would need to be kept so as to
> > be saved in JMX files]
> >
> > ==
> >
> > WDYT?
> >
> > S.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to