[prev in list] [next in list] [prev in thread] [next in thread] 

List:       grinder-use
Subject:    Re: [Grinder-use] New instrumentation behavior
From:       Philip Aston <philipa () mail ! com>
Date:       2010-06-11 6:50:23
Message-ID: 4C11DCAF.1050202 () mail ! com
[Download RAW message or body]


Hi Ludovic,

Your case is a different to Ernesto's, and should work fine from Jython:

     Test(1, "foo").record(UnderTest.firstTest)                       # 
Record all invocations of firstTest()
     Test(2, "bah").record(myUnderTestInstance.firstTest) # Record 
method invocations against instance (only)
     Test(3, "lah").record(UnderTest.secondTest)                  # 
Record all invocations of secondTest()

There's no way to express this in pure Java test code, since  I have not 
provided a workaround for its lack of function pointers.

(Ernesto's problem is that the API doesn't provide a way to have 
separate "handles" or "wrappers" of a single method/instance - hence the 
need to workaround by creating multiple request instances. This is still 
instrumenting the single HttpRequest class however).

- Phil

On 31/05/10 09:40, Ludovic Claude wrote:
> Hello Phil,
>
> I have the same remarks as Ernesto, because the behaviour of the new
> Grinder instrumentation differs from what happened before.
>
> Suppose you want to instrument a class with 2 methods:
>
> class UnderTest {
>      public void firstTest() {}
>      public void secondTest() {}
> }
>
> How can you instrument this class in order to be able to count
> separately the number of invocations to firstTest() and secondTest()?
> This was easy with the Python instrumentation, but now with the bytecode
> instrumentation, any call to firstTest() or secondTest() are aggregated
> under the same counter, associated with the class instance.
>
> Is there some plan to make the bytecode instrumentation more fine grained?
>
> Thanks,
> Ludovic
>
> Le 29/05/2010 17:17, Philip Aston a écrit :
>    
>> Ernesto,
>>
>> Apologies for the delay in responding.
>>
>> With the new instrumentation, you do need to create a different request
>> object for each test. The instrumentation for each test is "woven"
>> directly into the target object.
>>
>> - Phil
>>
>> On 06/05/10 01:52, Ernesto Domato wrote:
>>
>>      
>>> Hi, the script that I'm sending you used to use the old
>>> instrumentation and I was happy ;-)
>>>
>>> The problem that I have now with the behavior of the new
>>> instrumentation is that when I use the Test object on Auth2 method of
>>> NTLMAuthentication class (line 120 of the attached script) it doesn't
>>> work as expected. What I mean is that as the new instrumentation
>>> doesn't return a new instance of the proxy object, when you make a
>>> second request it is shown in the new Test results but is also
>>> aggregated on the previous one also.
>>>
>>> So,  ¿what is the best way to fix this script without having to create
>>> a new request object (with different variable name) that is the only
>>> way that I found to make it work correctly?. I'm asking this because
>>> I'm very new to Python and this script have just a few requests but
>>> the real one have almost 50 requests so if I have to rewrite it
>>> creating 50 new variables with a HTTPRequest it would be unpleasant.
>>>
>>> I hope that I could make me understand because I think that is almost
>>> obvious that English is not my native language, but if you have any
>>> other question please let me know :-)
>>>
>>> Thanks.
>>> Ernesto
>>>
>>>        


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
grinder-use mailing list
grinder-use@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/grinder-use

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic