jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Schumacher <felix.schumac...@internetallee.de>
Subject Re: PR235 and matching behaviour
Date Tue, 29 Nov 2016 19:45:56 GMT
Am 29.11.2016 um 20:26 schrieb Philippe Mouawad:
> On Tue, Nov 29, 2016 at 8:24 PM, Felix Schumacher <
> felix.schumacher@internetallee.de> wrote:
>
>> Hi all,
>>
>> I had a look at PR 235 and it addresses a valid bug. But I think the bug
>> goes a bit further than that.
>>
>> The patch addresses the case, where the processor first matches multiple
>> things with JSON Processor and after that gets an empty input for the
>> matching. In that case JMeter will leave the old values in refname_matchNr
>> and refname_<idx>.
>>
>> If on the other hand the first match is again a multi match and the second
>> gets processed with a matchnumber of "0". Then it gets a bit weird.
>> refname_matchNr will be set to the number of found elements, but no
>> elements will be stored in refname_<idx>.
>>
>> Thinking about this, I believe the correct result in both cases would be
>> to have no refname_matchNr and no refname_<idx> left in the vars.
>>
>> What do you think?
>>
>> I agree with your proposal
Ok, but when I implement the proposed behaviour, I get a unit test 
failure in TestJSONPostProcessor#testBug59609 where it is explicitly 
checked for refname_matchNr == 1 with matchnumber = "0".

I think the unit test is wrong and I would like to change it, to 
explicitly check that refname_matchNr is null.

What do you think?

Felix

>> Regards,
>>
>>   Felix
>>
>>
>


Mime
View raw message