You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jmeter-dev@jakarta.apache.org by Milamber <mi...@gmail.com> on 2009/10/01 01:23:06 UTC
Re: French translation Comparison Assertion & Visualizer
Le 30/09/2009 10:45, sebb a ecrit :
> On 29/09/2009, Milamber <mi...@gmail.com> wrote:
>
>> Hello,
>>
>> Le 28/09/2009 01:54, sebb a ecrit :
>>
>>
>>> On 27/09/2009, Milamber <mi...@gmail.com> wrote:
>>>
>>>
>>>
>>>> Hello,
>>>>
>>>> I works on French translation of new elements Comparison Assertion and
>>>> Comparison Assertion Visualizer. I have some questions:
>>>>
>>>> * Some messages like "Response time:" aren't internationalized. I would
>>>> like do this. Which resources files must be used?
>>>> - messages.properties
>>>> or
>>>> - CompareAssertionResources.properties
>>>>
>>>>
>>>>
>>> CompareAssertionResources.properties is used for the
>>>
>> CompareAssertion GUI
>>
>>> messages.properties is used for any GUIs which don't implement TestBean.
>>>
>>>
>>>
>> For message "Response time:" in ComparisonAssertion class (which implement
>> TestBean) but the message is only display in ComparisonVisualizer (which not
>> implement TestBean), can you confirm the best resource file ? (I think
>> messages.properties...)
>>
>
> Yes, messages.properties is used for any GUIs which don't implement TestBean.
>
> Though of course for a French translation you need to edit
> messages_fr.properties.
>
Yes ;)
> If the GUI uses a fixed string rather than a resource property, then
> translation involves:
> - change code to use resource
> - add property to messages.properties
> - add translations to messages_xx.properties
>
Ok, thanks for your instructions.
>
>>>
>>>> * In CompareAssertionResources.properties, I think
>>>>
>> this
>>
>>>> message isn't correct?
>>>> compareTime.shortDescription=Verify that all Samplers'
>>>> return times are within a given number of milliseconds
>>>>
>>>>
>>>>
>>> I think it needs to be qualified with "of each other".
>>> That could be inferred from that fact that the assertion compares
>>> samplers, but it would be better to be explicit.
>>>
>>>
>>>
>>>
>>>> In code, compare time behaviour verify that response time difference
>>>> between previous and current are within a given number of ms.
>>>> (But a 'break instruction' used if compare time failure is found at
>>>>
>> first
>>
>>>> element under the controller, other aren't never tested - that's a bug?)
>>>>
>>>>
>>>>
>>> I don't think so - because the first failure wins.
>>>
>>>
>>>
>> With this test plan :
>>
>> -Thread Group (1-1-1)
>> |--Simple Controller
>> |--Loop controller (5 loops)
>> |--Java Sampler
>> |--Compare Assertion (compare content false and compare time with 100
>> (ms))
>> |--Comparison Assertion Visualizer
>> |--View Results Tree
>>
>> loop1: response time 271 ms
>> loop2: response time 295 ms => success in CAV and VRT (noting display in
>> CAV, element tree is white)
>> loop3: response time 147 ms => failure in CAV and VRT (in CAV: left pane:
>> RT 295 and right pane: RT 147, element tree is red)
>> loop4: response time 284 ms => failure in CAV and VRT (because loop3
>> failed, no comparison with loop4 response time) (in CAV: left pane: RT 295
>> and right pane: RT 147 (not 284), element tree is red)
>> loop5: response time 275 ms => failure in CAV and VRT (because loop3
>> failed, no comparison with loop5 response time) (in CAV: left pane: RT 295
>> and right pane: RT 147 (not 275), element tree is red)
>>
>> The "comparison assertion" mark as a failure all samplers within a
>> controller when the first test failed has been found.
>> Perhaps, it would be better to add a sentence in manual, because I was in
>> mistake by the messages in Comparison Assertion Visualizer (always same
>> error message)
>>
>> Milamber
>>
>
> The code was copied from an old Java 5 development - it looked as
> though it might be useful. Unfortunately, there is no documentation of
> how it is intended to work.
>
> I'm not sure now how I would expect a comparison assertion to work:
> - should the first response be treated as the "good" sample, and
> subsequent responses compared to it?
>
That is this behaviour that I expect (that I understand in my mind when
when I talk comparison)
I made this changes in patch here (and some improvements)
https://issues.apache.org/bugzilla/show_bug.cgi?id=47907
The first is the 'good' sample and each sampler within controller is
compared to this first
> - should each response be compared with the previous response? If so,
> this would allow a steadily increasing (or decreasing) elapsed time
> without complaining. Also, if response 3 fails when compared with
> response 2, what should response 4 be compared against?
>
No, I don't thought this... because, for compare response time, we can
make this with a Duration Assertion.
And Content comparison, with a regexp extractor and Response assertion.
> If the behaviour needs to be changed to be more useful, now is the
> time to do it ... or maybe I should just remove the code again.
>
With some little improvements, I think that will be a good new
functionality. In all cases, we can find some ways to do (ie dynamic
time comparison / content comparison), but with this assertion and this
visualizer, we have a speed way to do this.
It's not very difficult to add a new field: Type Comparison: First
against Other(s) / Previous to Current / Mark on error at first failure
I can do this code changes, if you want.
(type list messages have to rewrite in good English)
Milamber
Re: French translation Comparison Assertion & Visualizer
Posted by Milamber <mi...@gmail.com>.
Hello,
I18N on Comparison Assertion & Visualizer are done :
https://issues.apache.org/bugzilla/show_bug.cgi?id=47907
I've add some enhancements for better visual effect in visualizer.
Please note: French translation to Comparison Ass/Vis are in this
bugzilla entry:
https://issues.apache.org/bugzilla/show_bug.cgi?id=47938
If you want, I can provide a new patch for add functional changes on
Comparison Assertion (first to other / current vs previous / mark on
error at first failure)
Thanks.
Milamber
Le 30/09/2009 23:31, sebb a ecrit :
> On 01/10/2009, Milamber <mi...@gmail.com> wrote:
>
>> Le 30/09/2009 10:45, sebb a ecrit :
>>
>>
>>> On 29/09/2009, Milamber <mi...@gmail.com> wrote:
>>>
>>>
>>>
>>>> Hello,
>>>>
>>>> Le 28/09/2009 01:54, sebb a ecrit :
>>>>
>>>>
>>>>
>>>>
>>>>> On 27/09/2009, Milamber <mi...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I works on French translation of new elements Comparison Assertion
>>>>>>
>> and
>>
>>>>>> Comparison Assertion Visualizer. I have some questions:
>>>>>>
>>>>>> * Some messages like "Response time:" aren't internationalized. I
>>>>>>
>> would
>>
>>>>>> like do this. Which resources files must be used?
>>>>>> - messages.properties
>>>>>> or
>>>>>> - CompareAssertionResources.properties
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> CompareAssertionResources.properties is used for the
>>>>>
>>>>>
>>>>>
>>>> CompareAssertion GUI
>>>>
>>>>
>>>>
>>>>> messages.properties is used for any GUIs which don't implement
>>>>>
>> TestBean.
>>
>>>>>
>>>>>
>>>>>
>>>> For message "Response time:" in ComparisonAssertion class (which
>>>>
>> implement
>>
>>>> TestBean) but the message is only display in ComparisonVisualizer (which
>>>>
>> not
>>
>>>> implement TestBean), can you confirm the best resource file ? (I think
>>>> messages.properties...)
>>>>
>>>>
>>>>
>>> Yes, messages.properties is used for any GUIs which don't implement
>>>
>> TestBean.
>>
>>> Though of course for a French translation you need to edit
>>> messages_fr.properties.
>>>
>>>
>>>
>> Yes ;)
>>
>>
>>
>>> If the GUI uses a fixed string rather than a resource property, then
>>> translation involves:
>>> - change code to use resource
>>> - add property to messages.properties
>>> - add translations to messages_xx.properties
>>>
>>>
>>>
>> Ok, thanks for your instructions.
>>
>>
>>
>>
>>>
>>>>>
>>>>>> * In CompareAssertionResources.properties, I think
>>>>>>
>>>>>>
>>>>>>
>>>> this
>>>>
>>>>
>>>>
>>>>>> message isn't correct?
>>>>>> compareTime.shortDescription=Verify that all
>>>>>>
>> Samplers'
>>
>>>>>> return times are within a given number of milliseconds
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> I think it needs to be qualified with "of each other".
>>>>> That could be inferred from that fact that the assertion compares
>>>>> samplers, but it would be better to be explicit.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> In code, compare time behaviour verify that response time
>>>>>>
>> difference
>>
>>>>>> between previous and current are within a given number of ms.
>>>>>> (But a 'break instruction' used if compare time failure is found at
>>>>>>
>>>>>>
>>>>>>
>>>> first
>>>>
>>>>
>>>>
>>>>>> element under the controller, other aren't never tested - that's a
>>>>>>
>> bug?)
>>
>>>>>>
>>>>>>
>>>>>>
>>>>> I don't think so - because the first failure wins.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> With this test plan :
>>>>
>>>> -Thread Group (1-1-1)
>>>> |--Simple Controller
>>>> |--Loop controller (5 loops)
>>>> |--Java Sampler
>>>> |--Compare Assertion (compare content false and compare time with 100
>>>> (ms))
>>>> |--Comparison Assertion Visualizer
>>>> |--View Results Tree
>>>>
>>>> loop1: response time 271 ms
>>>> loop2: response time 295 ms => success in CAV and VRT (noting display
>>>>
>> in
>>
>>>> CAV, element tree is white)
>>>> loop3: response time 147 ms => failure in CAV and VRT (in CAV: left
>>>>
>> pane:
>>
>>>> RT 295 and right pane: RT 147, element tree is red)
>>>> loop4: response time 284 ms => failure in CAV and VRT (because loop3
>>>> failed, no comparison with loop4 response time) (in CAV: left pane: RT
>>>>
>> 295
>>
>>>> and right pane: RT 147 (not 284), element tree is red)
>>>> loop5: response time 275 ms => failure in CAV and VRT (because loop3
>>>> failed, no comparison with loop5 response time) (in CAV: left pane: RT
>>>>
>> 295
>>
>>>> and right pane: RT 147 (not 275), element tree is red)
>>>>
>>>> The "comparison assertion" mark as a failure all samplers within a
>>>> controller when the first test failed has been found.
>>>> Perhaps, it would be better to add a sentence in manual, because I was
>>>>
>> in
>>
>>>> mistake by the messages in Comparison Assertion Visualizer (always same
>>>> error message)
>>>>
>>>> Milamber
>>>>
>>>>
>>>>
>>> The code was copied from an old Java 5 development - it looked as
>>> though it might be useful. Unfortunately, there is no documentation of
>>> how it is intended to work.
>>>
>>> I'm not sure now how I would expect a comparison assertion to work:
>>> - should the first response be treated as the "good" sample, and
>>> subsequent responses compared to it?
>>>
>>>
>>>
>> That is this behaviour that I expect (that I understand in my mind when
>> when I talk comparison)
>> I made this changes in patch here (and some improvements)
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=47907
>>
>> The first is the 'good' sample and each sampler within controller is
>> compared to this first
>>
>>
>
> Yes, I think that's good. It has the advantage that one only needs to
> store one sample, instead of the list which is used at present.
>
>
>>> - should each response be compared with the previous response? If so,
>>> this would allow a steadily increasing (or decreasing) elapsed time
>>> without complaining. Also, if response 3 fails when compared with
>>> response 2, what should response 4 be compared against?
>>>
>>>
>>>
>> No, I don't thought this... because, for compare response time, we can make
>> this with a Duration Assertion.
>> And Content comparison, with a regexp extractor and Response assertion.
>>
>>
>>
>>
>>> If the behaviour needs to be changed to be more useful, now is the
>>> time to do it ... or maybe I should just remove the code again.
>>>
>>>
>>>
>> With some little improvements, I think that will be a good new
>> functionality. In all cases, we can find some ways to do (ie dynamic time
>> comparison / content comparison), but with this assertion and this
>> visualizer, we have a speed way to do this.
>>
>> It's not very difficult to add a new field: Type Comparison: First against
>> Other(s) / Previous to Current / Mark on error at first failure
>> I can do this code changes, if you want.
>>
>> (type list messages have to rewrite in good English)
>>
>> Milamber
>>
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org
>
>
>
Re: French translation Comparison Assertion & Visualizer
Posted by sebb <se...@gmail.com>.
On 01/10/2009, Milamber <mi...@gmail.com> wrote:
>
>
> Le 30/09/2009 10:45, sebb a ecrit :
>
> > On 29/09/2009, Milamber <mi...@gmail.com> wrote:
> >
> >
> > > Hello,
> > >
> > > Le 28/09/2009 01:54, sebb a ecrit :
> > >
> > >
> > >
> > > > On 27/09/2009, Milamber <mi...@gmail.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > > Hello,
> > > > >
> > > > > I works on French translation of new elements Comparison Assertion
> and
> > > > > Comparison Assertion Visualizer. I have some questions:
> > > > >
> > > > > * Some messages like "Response time:" aren't internationalized. I
> would
> > > > > like do this. Which resources files must be used?
> > > > > - messages.properties
> > > > > or
> > > > > - CompareAssertionResources.properties
> > > > >
> > > > >
> > > > >
> > > > >
> > > > CompareAssertionResources.properties is used for the
> > > >
> > > >
> > > CompareAssertion GUI
> > >
> > >
> > > > messages.properties is used for any GUIs which don't implement
> TestBean.
> > > >
> > > >
> > > >
> > > >
> > > For message "Response time:" in ComparisonAssertion class (which
> implement
> > > TestBean) but the message is only display in ComparisonVisualizer (which
> not
> > > implement TestBean), can you confirm the best resource file ? (I think
> > > messages.properties...)
> > >
> > >
> >
> > Yes, messages.properties is used for any GUIs which don't implement
> TestBean.
> >
> > Though of course for a French translation you need to edit
> > messages_fr.properties.
> >
> >
> Yes ;)
>
>
> > If the GUI uses a fixed string rather than a resource property, then
> > translation involves:
> > - change code to use resource
> > - add property to messages.properties
> > - add translations to messages_xx.properties
> >
> >
>
> Ok, thanks for your instructions.
>
>
>
> >
> >
> > >
> > > >
> > > >
> > > > > * In CompareAssertionResources.properties, I think
> > > > >
> > > > >
> > > >
> > > this
> > >
> > >
> > > >
> > > > > message isn't correct?
> > > > > compareTime.shortDescription=Verify that all
> Samplers'
> > > > > return times are within a given number of milliseconds
> > > > >
> > > > >
> > > > >
> > > > >
> > > > I think it needs to be qualified with "of each other".
> > > > That could be inferred from that fact that the assertion compares
> > > > samplers, but it would be better to be explicit.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > > In code, compare time behaviour verify that response time
> difference
> > > > > between previous and current are within a given number of ms.
> > > > > (But a 'break instruction' used if compare time failure is found at
> > > > >
> > > > >
> > > >
> > > first
> > >
> > >
> > > >
> > > > > element under the controller, other aren't never tested - that's a
> bug?)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > I don't think so - because the first failure wins.
> > > >
> > > >
> > > >
> > > >
> > > With this test plan :
> > >
> > > -Thread Group (1-1-1)
> > > |--Simple Controller
> > > |--Loop controller (5 loops)
> > > |--Java Sampler
> > > |--Compare Assertion (compare content false and compare time with 100
> > > (ms))
> > > |--Comparison Assertion Visualizer
> > > |--View Results Tree
> > >
> > > loop1: response time 271 ms
> > > loop2: response time 295 ms => success in CAV and VRT (noting display
> in
> > > CAV, element tree is white)
> > > loop3: response time 147 ms => failure in CAV and VRT (in CAV: left
> pane:
> > > RT 295 and right pane: RT 147, element tree is red)
> > > loop4: response time 284 ms => failure in CAV and VRT (because loop3
> > > failed, no comparison with loop4 response time) (in CAV: left pane: RT
> 295
> > > and right pane: RT 147 (not 284), element tree is red)
> > > loop5: response time 275 ms => failure in CAV and VRT (because loop3
> > > failed, no comparison with loop5 response time) (in CAV: left pane: RT
> 295
> > > and right pane: RT 147 (not 275), element tree is red)
> > >
> > > The "comparison assertion" mark as a failure all samplers within a
> > > controller when the first test failed has been found.
> > > Perhaps, it would be better to add a sentence in manual, because I was
> in
> > > mistake by the messages in Comparison Assertion Visualizer (always same
> > > error message)
> > >
> > > Milamber
> > >
> > >
> >
> > The code was copied from an old Java 5 development - it looked as
> > though it might be useful. Unfortunately, there is no documentation of
> > how it is intended to work.
> >
> > I'm not sure now how I would expect a comparison assertion to work:
> > - should the first response be treated as the "good" sample, and
> > subsequent responses compared to it?
> >
> >
>
> That is this behaviour that I expect (that I understand in my mind when
> when I talk comparison)
> I made this changes in patch here (and some improvements)
> https://issues.apache.org/bugzilla/show_bug.cgi?id=47907
>
> The first is the 'good' sample and each sampler within controller is
> compared to this first
>
Yes, I think that's good. It has the advantage that one only needs to
store one sample, instead of the list which is used at present.
> > - should each response be compared with the previous response? If so,
> > this would allow a steadily increasing (or decreasing) elapsed time
> > without complaining. Also, if response 3 fails when compared with
> > response 2, what should response 4 be compared against?
> >
> >
>
> No, I don't thought this... because, for compare response time, we can make
> this with a Duration Assertion.
> And Content comparison, with a regexp extractor and Response assertion.
>
>
>
> > If the behaviour needs to be changed to be more useful, now is the
> > time to do it ... or maybe I should just remove the code again.
> >
> >
>
> With some little improvements, I think that will be a good new
> functionality. In all cases, we can find some ways to do (ie dynamic time
> comparison / content comparison), but with this assertion and this
> visualizer, we have a speed way to do this.
>
> It's not very difficult to add a new field: Type Comparison: First against
> Other(s) / Previous to Current / Mark on error at first failure
> I can do this code changes, if you want.
>
> (type list messages have to rewrite in good English)
>
> Milamber
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-dev-help@jakarta.apache.org