On Sun, Feb 26, 2017 at 1:44 PM, sebb <seb...@gmail.com> wrote: > On 26 February 2017 at 12:33, Philippe Mouawad > <philippe.moua...@gmail.com> wrote: > > On Sun, Feb 26, 2017 at 1:15 PM, sebb <seb...@gmail.com> wrote: > > > >> On 26 February 2017 at 09:52, Philippe Mouawad > >> <philippe.moua...@gmail.com> wrote: > >> > Hello, > >> > This element might be more useful if we can make some enhancements to > it: > >> > > >> > - First rename it as its name is far from clear. Something like > Mail > >> > Alerter > >> > - Make it send notifications on richer conditions: > >> > - Percentile 90 of response time (Excluding Transaction > Controller) > >> > reaching a limit > >> > - Errors percentage reaching a limit > >> > - Burst in error percentage > >> > - ... > >> > - Possibly be able to express a rule in Groovy > >> > > >> > Currently it seems to me far from useful as is. > >> > >> I suggest you ask on the User list how it is being used. > >> > >> Also, I would be wary of adding too much functionality into the > listener. > >> It should just be a means to send the email, the same as other > >> Listeners are a means to displaying results or recording them in a > >> file or database. > >> Error checks should be done by Assertions. > >> > > In my understanding Assertion applies on every sample. Can it apply to a > > history of samplers ? > > Listeners also apply to each sample, yet the Mailer Visualizer is able > to look at history, so Assertions can use the same technique. > > > Maybe a simple addition would be to allow Mailer Visualizer to send a > mail > > based on variable or property value (true/ false). > > This would make it very flexible. We could this way combine it with > > GenerateSummary Result or a dedicated "Alert" listener which could set > this > > variable or property. > > That would be better, but the "Alert" test element should be an > Assertion not a Listener. > Its usage would be confusing . Assertion are here to mark a sampler in error, so you could randomly get any sampler marked in error whenever the alert conditions are met. A listener is more "global" as such it seems to me a better place for that.
> > This would allow it to be more general; e.g. one could stop a test if > the error percentage was too high. > > > > >> As far as possible, each test element should have a single role. > >> This reduces duplication and allows easier testing. > >> > > I agree > > > >> > >> > > >> > Regards > >> > > >> > Philippe > >> > > > > > > > > -- > > Cordialement. > > Philippe Mouawad. > -- Cordialement. Philippe Mouawad.
