I still see "Log Errors" on the listener being useful too. As for non- gui running, I think the new jmx file format makes editing listener properties easy enough to be something to consider.
-Mike On Mon, 2005-05-09 at 16:07 +0100, sebb wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
