mockobjects-java-users — For people who use the mock objects libraries

Re: [MO-java-users] RegEx-like method names for matchAndReturn?

[<st...@m3...>]

That's certainly the intention. It's such an obvious thing to do.

On 18 July, 2003, Joe Walnes wrote:
> Not sure if this has been mentioned yet...
>=20
> It would be much more flexible if the first argument of all the match=20
> and expect methods (i.e. the name) took a Constraint instead of a String.

Re: [MO-java-users] RegEx-like method names for matchAndReturn?

[Joe W. <jo...@tr...>]

Not sure if this has been mentioned yet...

It would be much more flexible if the first argument of all the match 
and expect methods (i.e. the name) took a Constraint instead of a String.

-joe

Nat Pryce wrote:

>The MockObjects website has example code that does almost exactly what you
>want.
>
>Look at http://www.mockobjects.com/wiki/CallableDecorators
>
>Cheers,
>            Nat.
>_______________________
>Dr. Nathaniel Pryce
>B13media Ltd.
>http://www.b13media.com
>+44 (0)7712 526 661
>
>----- Original Message -----
>From: <mai...@ji...>
>To: <moc...@li...>
>Sent: Thursday, July 17, 2003 7:26 PM
>Subject: [MO-java-users] RegEx-like method names for matchAndReturn?
>
>
>  
>
>>Is there any way to have Mock.matchAndReturn() match against method
>>names using wildcards?  For example, I'd like to:
>>
>>Mock mock = new Mock( InterfaceWithLotsOfBooleans.class );
>>mock.matchAndReturn( "is*", false );
>>
>>Which for any isProperty method call would return false.
>>
>>I figure that some kind of callable subclass is necessary, but with very
>>little in the way of javadocs (and the unit tests aren't helpful here),
>>I don't know where to go.
>>
>>;ted
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a single machine.
>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>_______________________________________________
>>Mockobjects-java-users mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
>>    
>>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: VM Ware
>With VMware you can run multiple operating systems on a single machine.
>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>_______________________________________________
>Mockobjects-java-users mailing list
>Moc...@li...
>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
>  
>

RE: [MO-java-users] RegEx-like method names for matchAndReturn?

[Jitterpig D. <jit...@ji...>]

I looked at that page already, but it doesn't seem to be compatible with
the latest mock objects download (0.09).  Mainly, the version of Mock
that I have doesn't implement the add() method...unless I'm looking in
the wrong place?

Thanks,
Ted

> -----Original Message-----
> From: moc...@li... 
> [mailto:moc...@li...] 
> On Behalf Of Nat Pryce
> Sent: Thursday, July 17, 2003 12:44 PM
> 
> The MockObjects website has example code that does almost 
> exactly what you
> want.
> 
> Look at http://www.mockobjects.com/wiki/CallableDecorators
> 
> Cheers,
>             Nat.
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
> 
> ----- Original Message -----
> From: <mai...@ji...>
> To: <moc...@li...>
> Sent: Thursday, July 17, 2003 7:26 PM
> Subject: [MO-java-users] RegEx-like method names for matchAndReturn?
> 
> 
> > Is there any way to have Mock.matchAndReturn() match against method
> > names using wildcards?  For example, I'd like to:
> >
> > Mock mock = new Mock( InterfaceWithLotsOfBooleans.class );
> > mock.matchAndReturn( "is*", false );
> >
> > Which for any isProperty method call would return false.
> >
> > I figure that some kind of callable subclass is necessary, 
> but with very
> > little in the way of javadocs (and the unit tests aren't 
> helpful here),
> > I don't know where to go.
> >
> > ;ted
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: VM Ware
> > With VMware you can run multiple operating systems on a 
> single machine.
> > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
> machines at the
> > same time. Free trial click here: 
> http://www.vmware.com/wl/offer/345/0
> > 
> _______________________________________________
> > Mockobjects-java-users mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a 
> single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
> machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 

Re: [MO-java-users] setting attributes in a mock request

[Steve F. <st...@m3...>]

I guess someone was trying to make a clear distinction between the two 
concepts. After all, sometimes you just don't care what the request 
parameters are, you just want the value returned. The risk is of 
overspecifying the test so that it breaks when unimportant things 
change. In practice, this is probably too subtle.

Roll on the dynamic libraries (at least servlets are defined using 
interfaces).

S.

Ext...@no... wrote:
>>The idea is that you should preload your attributes in the order in 
>>which they are requested, and then they'll just be returned 
>>as the code 
>>runs. It's not actually doing a lookup. Checking which attributes are 
>>asked for is actually a separate concept and handled by a different 
>>expectation. There are some arguments for doing this but it 
>>does look a 
>>little clumsy.
> 
> 
> What are the arguments for this approach?  I encountered the same problem a while back and I'm still scratching my head :-)

Re: [MO-java-users] RegEx-like method names for matchAndReturn?

[Nat P. <nat...@b1...>]

The MockObjects website has example code that does almost exactly what you
want.

Look at http://www.mockobjects.com/wiki/CallableDecorators

Cheers,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: <mai...@ji...>
To: <moc...@li...>
Sent: Thursday, July 17, 2003 7:26 PM
Subject: [MO-java-users] RegEx-like method names for matchAndReturn?


> Is there any way to have Mock.matchAndReturn() match against method
> names using wildcards?  For example, I'd like to:
>
> Mock mock = new Mock( InterfaceWithLotsOfBooleans.class );
> mock.matchAndReturn( "is*", false );
>
> Which for any isProperty method call would return false.
>
> I figure that some kind of callable subclass is necessary, but with very
> little in the way of javadocs (and the unit tests aren't helpful here),
> I don't know where to go.
>
> ;ted
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

[MO-java-users] RegEx-like method names for matchAndReturn?

[<mai...@ji...>]

Is there any way to have Mock.matchAndReturn() match against method
names using wildcards?  For example, I'd like to:

Mock mock = new Mock( InterfaceWithLotsOfBooleans.class );
mock.matchAndReturn( "is*", false );

Which for any isProperty method call would return false.

I figure that some kind of callable subclass is necessary, but with very
little in the way of javadocs (and the unit tests aren't helpful here),
I don't know where to go.

;ted

Re: [MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

Nat,

Nat Pryce wrote:
> The putObjectToReturn and getNextReturnObject methods are more descriptive
> and check the expectations.  Using a hashtable does not check expectations:
> if the class under test asks for an unexpected attribute it will receive a
> null value and eventually throw a null pointer exception sometime down the
> line. Using getNextReturnObject to ask for an unexpected attribute will fail
> immediately with a descriptive error message.

Ok, got it - thanks.

> For documentation, read through the tests for the library itself.  They show
> it in use, and should describe the behaviour of the classes in a readable
> manner.

Thanks, I'll check those out.

Cheers,
--Bill

> Finally, I don't know why the hash table is exposed.  Perhaps somebody
> needed to pass a hashtable to some other piece of code.  I would avoid using
> it.
> 
> Cheers,
>             Nat.
> 
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
> 
> ----- Original Message -----
> From: "Bill Lynch" <bi...@ji...>
> To: <moc...@li...>; "Nat Pryce"
> <nat...@b1...>
> Sent: Thursday, July 17, 2003 4:06 PM
> Subject: Re: [MO-java-users] setting attributes in a mock request
> 
> 
> 
>>Nat et al,
>>
>>Thanks for the advice - I can change that code (I'm new to the class). I
>>have a few more questions:
>>
>>1) Why should I keep using a ReturnObjectBag as an internal object? In
>>my example, does it its use benefit me, or can I use it in a better way?
>>
>>2) If I shouldn't mess with the internal Hashtable, why is it exposed?
>>Seems like poor design then.
>>
>>3) Any reason there's no Javadocs for any of these classes? :) Having
>>better documentation would have steered me away from using the internal
>>hashtable probably.
>>
>>Cheers,
>>--Bill
>>
>>Nat Pryce wrote:
>>
>>
>>>Try using the putObjectToReturn and getNextReturnObject methods rather
> 
> than
> 
>>>messing around with the ReturnObjectBag's internal hash table.
>>>
>>>Cheers,
>>>            Nat.
>>
>> >
>>
>>>----- Original Message -----
>>>From: Bill Lynch
>>>To: <moc...@li...>
>>>Sent: Thursday, July 17, 2003 2:37 PM
>>>Subject: Re: [MO-java-users] setting attributes in a mock request
>>>
>>>
>>>>Guys,
>>>>
>>>>I took Steve's advice and created my own extention to
>>>>MockHttpServletRequest - my first attempt is below:
>>>>
>>>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>>>
>>>>    private Hashtable attributes;
>>>>
>>>>    public JiveMockHttpServletRequest() {
>>>>        attributes = new Hashtable();
>>>>    }
>>>>
>>>>    public Object getAttribute(String s) {
>>>>        return attributes.get(s);
>>>>    }
>>>>
>>>>    public Enumeration getAttributeNames() {
>>>>        return attributes.elements();
>>>>    }
>>>>
>>>>    public void setAttribute(String s, Object o) {
>>>>        attributes.put(s,o);
>>>>    }
>>>>}
>>>>
>>>>After doing this and reading Jeff's mail I implemented it with a
>>>>ReturnObjectBag - however, I don't see what that buys me:
>>>>
>>>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>>>
>>>>    private ReturnObjectBag attributes;
>>>>
>>>>    public MyMockHttpServletRequest() {
>>>>        attributes = new ReturnObjectBag("attributes");
>>>>    }
>>>>
>>>>    public Object getAttribute(String s) {
>>>>        return attributes.getHashTable().get(s);
>>>>    }
>>>>
>>>>    public Enumeration getAttributeNames() {
>>>>        return attributes.getHashTable().elements();
>>>>    }
>>>>
>>>>    public void setAttribute(String s, Object o) {
>>>>        attributes.getHashTable().put(s,o);
>>>>    }
>>>>}
>>>>
>>>>Is there a benefit to either approach? Both work perfectly in my test
>>>>case and I'm more inclined to go with the first approach just because
>>>>it's simpler (and the ReturnObjectBag does nothing for me in this case).
>>>>
>>>>Cheers,
>>>>--Bill
>>>>
>>>>Jeff Martin wrote:
>>>>
>>>>
>>>>>Should probably be a ReturnObjectBag as this lets you setup a list of
>>>>>return values for a key.
>>>>>
>>>>>
>>>>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
>>>>>
>>>>>
>>>>>
>>>>>>This implementation /is/ a little hazy.
>>>>>>
>>>>>>The idea is that you should preload your attributes in the order in
>>>>>>which they are requested, and then they'll just be returned as the
> 
> code
> 
>>>>>>runs. It's not actually doing a lookup. Checking which attributes are
>>>>>>asked for is actually a separate concept and handled by a different
>>>>>>expectation. There are some arguments for doing this but it does look
> 
> a
> 
>>>>>>little clumsy.
>>>>>>
>>>>>>If you don't like this, I suggest you replace this part of the mock
>>>>>>request with an ExpectationMap which might be closer to the behaviour
>>>>>>you want.
>>>>>>
>>>>>>S.
>>>>>>
>>>>>>Bill Lynch wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>All,
>>>>>>>
>>>>>>>I haven't been able to figure out how to set attributes in a
>>>>>>>MockHttpServletRequest. I searched the mailing list archives for
> 
> clues,
> 
>>>>>>>but didn't find any (and there's no javadocs for that class!).
>>>>>>>
>>>>>>>The method that looks like it might work only takes one param:
>>>>>>>
>>>>>>>request.setupGetAttribute(Object)
>>>>>>>
>>>>>>>I'd expect that to be
>>>>>>>
>>>>>>>request.setupGetAttribute(String, Object)
>>>>>>>
>>>>>>>I've also tried passing in a vector of name/value pairs to that
> 
> method,
> 
>>>>>>>but when I call getAttribute(String) on that request object I get
> 
> this
> 
>>>>>>>error:
>>>>>>>
>>>>>>>There was 1 failure:
>>>>>>>1)
>>>>
>>>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedErro
> 
> r
> 
>>>:
>>>
>>>
>>>>>>>attributes has run out of objects.
>>>>>>>  at
>>>>
>>>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:
> 
> 6
> 
>>>1)
>>>
>>>
>>>>>>>  at
>>>>
>>>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServ
> 
> l
> 
>>>etRequest.java:58)
>>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a single machine.
>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>_______________________________________________
>>Mockobjects-java-users mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

-- 
----------------------------------
Bill Lynch, Jive Software
bi...@ji...

Re: [MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

Jeff,

>>Thanks for the advice - I can change that code (I'm new to the class). I 
>>have a few more questions:
>>
>>1) Why should I keep using a ReturnObjectBag as an internal object? In 
>>my example, does it its use benefit me, or can I use it in a better way?
> 
> Simplest (not best) example is this. How can you tell if your code is
> doing this.
> 
> for(int i=0;i<100000;i++){
>   att = request.getAttribute("name");
> }
> 
> or this
> 
> att = request.getAttribute("name");

So in the ReturnObjectBag's internal ReturnObjectList remove the object 
it returns from the list?

>>2) If I shouldn't mess with the internal Hashtable, why is it exposed? 
>>Seems like poor design then. 
> 
> Not bad design, just unusual environmental pressures, it's probably
> vestigial by now.

Gotcha.

>>3) Any reason there's no Javadocs for any of these classes? :) Having 
>>better documentation would have steered me away from using the internal 
>>hashtable probably.
> 
> cough,
> http://mockobjects.sourceforge.net/javadoc/1.4/com/mockobjects/ReturnObjectBag.html

Woa, my bad! Clearly I didn't dig deep enough. :)

Thanks,
--Bill



>>Nat Pryce wrote:
>>
>>
>>>Try using the putObjectToReturn and getNextReturnObject methods rather than
>>>messing around with the ReturnObjectBag's internal hash table.
>>>
>>>Cheers,
>>>            Nat.
>>
>> >
>>
>>>----- Original Message -----
>>>From: Bill Lynch
>>>To: <moc...@li...>
>>>Sent: Thursday, July 17, 2003 2:37 PM
>>>Subject: Re: [MO-java-users] setting attributes in a mock request
>>>
>>>
>>>>Guys,
>>>>
>>>>I took Steve's advice and created my own extention to
>>>>MockHttpServletRequest - my first attempt is below:
>>>>
>>>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>>>
>>>>    private Hashtable attributes;
>>>>
>>>>    public JiveMockHttpServletRequest() {
>>>>        attributes = new Hashtable();
>>>>    }
>>>>
>>>>    public Object getAttribute(String s) {
>>>>        return attributes.get(s);
>>>>    }
>>>>
>>>>    public Enumeration getAttributeNames() {
>>>>        return attributes.elements();
>>>>    }
>>>>
>>>>    public void setAttribute(String s, Object o) {
>>>>        attributes.put(s,o);
>>>>    }
>>>>}
>>>>
>>>>After doing this and reading Jeff's mail I implemented it with a
>>>>ReturnObjectBag - however, I don't see what that buys me:
>>>>
>>>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>>>
>>>>    private ReturnObjectBag attributes;
>>>>
>>>>    public MyMockHttpServletRequest() {
>>>>        attributes = new ReturnObjectBag("attributes");
>>>>    }
>>>>
>>>>    public Object getAttribute(String s) {
>>>>        return attributes.getHashTable().get(s);
>>>>    }
>>>>
>>>>    public Enumeration getAttributeNames() {
>>>>        return attributes.getHashTable().elements();
>>>>    }
>>>>
>>>>    public void setAttribute(String s, Object o) {
>>>>        attributes.getHashTable().put(s,o);
>>>>    }
>>>>}
>>>>
>>>>Is there a benefit to either approach? Both work perfectly in my test
>>>>case and I'm more inclined to go with the first approach just because
>>>>it's simpler (and the ReturnObjectBag does nothing for me in this case).
>>>>
>>>>Cheers,
>>>>--Bill
>>>>
>>>>Jeff Martin wrote:
>>>>
>>>>
>>>>>Should probably be a ReturnObjectBag as this lets you setup a list of
>>>>>return values for a key.
>>>>>
>>>>>
>>>>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
>>>>>
>>>>>
>>>>>
>>>>>>This implementation /is/ a little hazy.
>>>>>>
>>>>>>The idea is that you should preload your attributes in the order in
>>>>>>which they are requested, and then they'll just be returned as the code
>>>>>>runs. It's not actually doing a lookup. Checking which attributes are
>>>>>>asked for is actually a separate concept and handled by a different
>>>>>>expectation. There are some arguments for doing this but it does look a
>>>>>>little clumsy.
>>>>>>
>>>>>>If you don't like this, I suggest you replace this part of the mock
>>>>>>request with an ExpectationMap which might be closer to the behaviour
>>>>>>you want.
>>>>>>
>>>>>>S.
>>>>>>
>>>>>>Bill Lynch wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>All,
>>>>>>>
>>>>>>>I haven't been able to figure out how to set attributes in a
>>>>>>>MockHttpServletRequest. I searched the mailing list archives for clues,
>>>>>>>but didn't find any (and there's no javadocs for that class!).
>>>>>>>
>>>>>>>The method that looks like it might work only takes one param:
>>>>>>>
>>>>>>>request.setupGetAttribute(Object)
>>>>>>>
>>>>>>>I'd expect that to be
>>>>>>>
>>>>>>>request.setupGetAttribute(String, Object)
>>>>>>>
>>>>>>>I've also tried passing in a vector of name/value pairs to that method,
>>>>>>>but when I call getAttribute(String) on that request object I get this
>>>>>>>error:
>>>>>>>
>>>>>>>There was 1 failure:
>>>>>>>1)
>>>>
>>>>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError
>>>
>>>:
>>>
>>>
>>>>>>>attributes has run out of objects.
>>>>>>>  at
>>>>
>>>>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:6
>>>
>>>1)
>>>
>>>
>>>>>>>  at
>>>>
>>>>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServl
>>>
>>>etRequest.java:58)
>>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by: VM Ware
>>With VMware you can run multiple operating systems on a single machine.
>>WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
>>same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
>>_______________________________________________
>>Mockobjects-java-users mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

-- 
----------------------------------
Bill Lynch, Jive Software
bi...@ji...

Re: [MO-java-users] setting attributes in a mock request

[Nat P. <nat...@b1...>]

The putObjectToReturn and getNextReturnObject methods are more descriptive
and check the expectations.  Using a hashtable does not check expectations:
if the class under test asks for an unexpected attribute it will receive a
null value and eventually throw a null pointer exception sometime down the
line. Using getNextReturnObject to ask for an unexpected attribute will fail
immediately with a descriptive error message.

For documentation, read through the tests for the library itself.  They show
it in use, and should describe the behaviour of the classes in a readable
manner.

Finally, I don't know why the hash table is exposed.  Perhaps somebody
needed to pass a hashtable to some other piece of code.  I would avoid using
it.

Cheers,
            Nat.

_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: "Bill Lynch" <bi...@ji...>
To: <moc...@li...>; "Nat Pryce"
<nat...@b1...>
Sent: Thursday, July 17, 2003 4:06 PM
Subject: Re: [MO-java-users] setting attributes in a mock request


> Nat et al,
>
> Thanks for the advice - I can change that code (I'm new to the class). I
> have a few more questions:
>
> 1) Why should I keep using a ReturnObjectBag as an internal object? In
> my example, does it its use benefit me, or can I use it in a better way?
>
> 2) If I shouldn't mess with the internal Hashtable, why is it exposed?
> Seems like poor design then.
>
> 3) Any reason there's no Javadocs for any of these classes? :) Having
> better documentation would have steered me away from using the internal
> hashtable probably.
>
> Cheers,
> --Bill
>
> Nat Pryce wrote:
>
> > Try using the putObjectToReturn and getNextReturnObject methods rather
than
> > messing around with the ReturnObjectBag's internal hash table.
> >
> > Cheers,
> >             Nat.
>  >
> > ----- Original Message -----
> > From: Bill Lynch
> > To: <moc...@li...>
> > Sent: Thursday, July 17, 2003 2:37 PM
> > Subject: Re: [MO-java-users] setting attributes in a mock request
> >
> >>Guys,
> >>
> >>I took Steve's advice and created my own extention to
> >>MockHttpServletRequest - my first attempt is below:
> >>
> >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> >>
> >>     private Hashtable attributes;
> >>
> >>     public JiveMockHttpServletRequest() {
> >>         attributes = new Hashtable();
> >>     }
> >>
> >>     public Object getAttribute(String s) {
> >>         return attributes.get(s);
> >>     }
> >>
> >>     public Enumeration getAttributeNames() {
> >>         return attributes.elements();
> >>     }
> >>
> >>     public void setAttribute(String s, Object o) {
> >>         attributes.put(s,o);
> >>     }
> >>}
> >>
> >>After doing this and reading Jeff's mail I implemented it with a
> >>ReturnObjectBag - however, I don't see what that buys me:
> >>
> >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> >>
> >>     private ReturnObjectBag attributes;
> >>
> >>     public MyMockHttpServletRequest() {
> >>         attributes = new ReturnObjectBag("attributes");
> >>     }
> >>
> >>     public Object getAttribute(String s) {
> >>         return attributes.getHashTable().get(s);
> >>     }
> >>
> >>     public Enumeration getAttributeNames() {
> >>         return attributes.getHashTable().elements();
> >>     }
> >>
> >>     public void setAttribute(String s, Object o) {
> >>         attributes.getHashTable().put(s,o);
> >>     }
> >>}
> >>
> >>Is there a benefit to either approach? Both work perfectly in my test
> >>case and I'm more inclined to go with the first approach just because
> >>it's simpler (and the ReturnObjectBag does nothing for me in this case).
> >>
> >>Cheers,
> >>--Bill
> >>
> >>Jeff Martin wrote:
> >>
> >>>Should probably be a ReturnObjectBag as this lets you setup a list of
> >>>return values for a key.
> >>>
> >>>
> >>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> >>>
> >>>
> >>>>This implementation /is/ a little hazy.
> >>>>
> >>>>The idea is that you should preload your attributes in the order in
> >>>>which they are requested, and then they'll just be returned as the
code
> >>>>runs. It's not actually doing a lookup. Checking which attributes are
> >>>>asked for is actually a separate concept and handled by a different
> >>>>expectation. There are some arguments for doing this but it does look
a
> >>>>little clumsy.
> >>>>
> >>>>If you don't like this, I suggest you replace this part of the mock
> >>>>request with an ExpectationMap which might be closer to the behaviour
> >>>>you want.
> >>>>
> >>>>S.
> >>>>
> >>>>Bill Lynch wrote:
> >>>>
> >>>>
> >>>>>All,
> >>>>>
> >>>>>I haven't been able to figure out how to set attributes in a
> >>>>>MockHttpServletRequest. I searched the mailing list archives for
clues,
> >>>>>but didn't find any (and there's no javadocs for that class!).
> >>>>>
> >>>>>The method that looks like it might work only takes one param:
> >>>>>
> >>>>>request.setupGetAttribute(Object)
> >>>>>
> >>>>>I'd expect that to be
> >>>>>
> >>>>>request.setupGetAttribute(String, Object)
> >>>>>
> >>>>>I've also tried passing in a vector of name/value pairs to that
method,
> >>>>>but when I call getAttribute(String) on that request object I get
this
> >>>>>error:
> >>>>>
> >>>>>There was 1 failure:
> >>>>>1)
> >>
>
>>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedErro
r
> >
> > :
> >
> >>>>>attributes has run out of objects.
> >>>>>   at
> >>
>
>>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:
6
> >
> > 1)
> >
> >>>>>   at
> >>
>
>>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServ
l
> >
> > etRequest.java:58)
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

Re: [MO-java-users] setting attributes in a mock request

[Jeff M. <je...@cu...>]

Maybe a slightly better example is what happens when you do this.

//test setup
setAttribute("att", null);

//actual code
if(getAttribute("wrong att")==null){
	// do something
}


On Thu, 2003-07-17 at 16:34, Jeff Martin wrote:
> On Thu, 2003-07-17 at 16:06, Bill Lynch wrote:
> > Nat et al,
> > 
> > Thanks for the advice - I can change that code (I'm new to the class). I 
> > have a few more questions:
> > 
> > 1) Why should I keep using a ReturnObjectBag as an internal object? In 
> > my example, does it its use benefit me, or can I use it in a better way?
> Simplest (not best) example is this. How can you tell if your code is
> doing this.
> 
> for(int i=0;i<100000;i++){
>   att = request.getAttribute("name");
> }
> 
> or this
> 
> att = request.getAttribute("name");
> 
> > 
> > 2) If I shouldn't mess with the internal Hashtable, why is it exposed? 
> > Seems like poor design then.
> 
> Not bad design, just unusual environmental pressures, it's probably
> vestigial by now.
> 
> >
> > 3) Any reason there's no Javadocs for any of these classes? :) Having 
> > better documentation would have steered me away from using the internal 
> > hashtable probably.
> > 
> 
> cough,
> http://mockobjects.sourceforge.net/javadoc/1.4/com/mockobjects/ReturnObjectBag.html
> 
> > 
> > Cheers,
> > --Bill
> > 
> > Nat Pryce wrote:
> > 
> > > Try using the putObjectToReturn and getNextReturnObject methods rather than
> > > messing around with the ReturnObjectBag's internal hash table.
> > > 
> > > Cheers,
> > >             Nat.
> >  >
> > > ----- Original Message -----
> > > From: Bill Lynch
> > > To: <moc...@li...>
> > > Sent: Thursday, July 17, 2003 2:37 PM
> > > Subject: Re: [MO-java-users] setting attributes in a mock request
> > > 
> > >>Guys,
> > >>
> > >>I took Steve's advice and created my own extention to
> > >>MockHttpServletRequest - my first attempt is below:
> > >>
> > >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> > >>
> > >>     private Hashtable attributes;
> > >>
> > >>     public JiveMockHttpServletRequest() {
> > >>         attributes = new Hashtable();
> > >>     }
> > >>
> > >>     public Object getAttribute(String s) {
> > >>         return attributes.get(s);
> > >>     }
> > >>
> > >>     public Enumeration getAttributeNames() {
> > >>         return attributes.elements();
> > >>     }
> > >>
> > >>     public void setAttribute(String s, Object o) {
> > >>         attributes.put(s,o);
> > >>     }
> > >>}
> > >>
> > >>After doing this and reading Jeff's mail I implemented it with a
> > >>ReturnObjectBag - however, I don't see what that buys me:
> > >>
> > >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> > >>
> > >>     private ReturnObjectBag attributes;
> > >>
> > >>     public MyMockHttpServletRequest() {
> > >>         attributes = new ReturnObjectBag("attributes");
> > >>     }
> > >>
> > >>     public Object getAttribute(String s) {
> > >>         return attributes.getHashTable().get(s);
> > >>     }
> > >>
> > >>     public Enumeration getAttributeNames() {
> > >>         return attributes.getHashTable().elements();
> > >>     }
> > >>
> > >>     public void setAttribute(String s, Object o) {
> > >>         attributes.getHashTable().put(s,o);
> > >>     }
> > >>}
> > >>
> > >>Is there a benefit to either approach? Both work perfectly in my test
> > >>case and I'm more inclined to go with the first approach just because
> > >>it's simpler (and the ReturnObjectBag does nothing for me in this case).
> > >>
> > >>Cheers,
> > >>--Bill
> > >>
> > >>Jeff Martin wrote:
> > >>
> > >>>Should probably be a ReturnObjectBag as this lets you setup a list of
> > >>>return values for a key.
> > >>>
> > >>>
> > >>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> > >>>
> > >>>
> > >>>>This implementation /is/ a little hazy.
> > >>>>
> > >>>>The idea is that you should preload your attributes in the order in
> > >>>>which they are requested, and then they'll just be returned as the code
> > >>>>runs. It's not actually doing a lookup. Checking which attributes are
> > >>>>asked for is actually a separate concept and handled by a different
> > >>>>expectation. There are some arguments for doing this but it does look a
> > >>>>little clumsy.
> > >>>>
> > >>>>If you don't like this, I suggest you replace this part of the mock
> > >>>>request with an ExpectationMap which might be closer to the behaviour
> > >>>>you want.
> > >>>>
> > >>>>S.
> > >>>>
> > >>>>Bill Lynch wrote:
> > >>>>
> > >>>>
> > >>>>>All,
> > >>>>>
> > >>>>>I haven't been able to figure out how to set attributes in a
> > >>>>>MockHttpServletRequest. I searched the mailing list archives for clues,
> > >>>>>but didn't find any (and there's no javadocs for that class!).
> > >>>>>
> > >>>>>The method that looks like it might work only takes one param:
> > >>>>>
> > >>>>>request.setupGetAttribute(Object)
> > >>>>>
> > >>>>>I'd expect that to be
> > >>>>>
> > >>>>>request.setupGetAttribute(String, Object)
> > >>>>>
> > >>>>>I've also tried passing in a vector of name/value pairs to that method,
> > >>>>>but when I call getAttribute(String) on that request object I get this
> > >>>>>error:
> > >>>>>
> > >>>>>There was 1 failure:
> > >>>>>1)
> > >>
> > >>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError
> > > 
> > > :
> > > 
> > >>>>>attributes has run out of objects.
> > >>>>>   at
> > >>
> > >>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:6
> > > 
> > > 1)
> > > 
> > >>>>>   at
> > >>
> > >>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServl
> > > 
> > > etRequest.java:58)
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: VM Ware
> > With VMware you can run multiple operating systems on a single machine.
> > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> > _______________________________________________
> > Mockobjects-java-users mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/

Re: [MO-java-users] setting attributes in a mock request

[Jeff M. <je...@cu...>]

On Thu, 2003-07-17 at 16:06, Bill Lynch wrote:
> Nat et al,
> 
> Thanks for the advice - I can change that code (I'm new to the class). I 
> have a few more questions:
> 
> 1) Why should I keep using a ReturnObjectBag as an internal object? In 
> my example, does it its use benefit me, or can I use it in a better way?
Simplest (not best) example is this. How can you tell if your code is
doing this.

for(int i=0;i<100000;i++){
  att = request.getAttribute("name");
}

or this

att = request.getAttribute("name");

> 
> 2) If I shouldn't mess with the internal Hashtable, why is it exposed? 
> Seems like poor design then.

Not bad design, just unusual environmental pressures, it's probably
vestigial by now.

>
> 3) Any reason there's no Javadocs for any of these classes? :) Having 
> better documentation would have steered me away from using the internal 
> hashtable probably.
> 

cough,
http://mockobjects.sourceforge.net/javadoc/1.4/com/mockobjects/ReturnObjectBag.html

> 
> Cheers,
> --Bill
> 
> Nat Pryce wrote:
> 
> > Try using the putObjectToReturn and getNextReturnObject methods rather than
> > messing around with the ReturnObjectBag's internal hash table.
> > 
> > Cheers,
> >             Nat.
>  >
> > ----- Original Message -----
> > From: Bill Lynch
> > To: <moc...@li...>
> > Sent: Thursday, July 17, 2003 2:37 PM
> > Subject: Re: [MO-java-users] setting attributes in a mock request
> > 
> >>Guys,
> >>
> >>I took Steve's advice and created my own extention to
> >>MockHttpServletRequest - my first attempt is below:
> >>
> >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> >>
> >>     private Hashtable attributes;
> >>
> >>     public JiveMockHttpServletRequest() {
> >>         attributes = new Hashtable();
> >>     }
> >>
> >>     public Object getAttribute(String s) {
> >>         return attributes.get(s);
> >>     }
> >>
> >>     public Enumeration getAttributeNames() {
> >>         return attributes.elements();
> >>     }
> >>
> >>     public void setAttribute(String s, Object o) {
> >>         attributes.put(s,o);
> >>     }
> >>}
> >>
> >>After doing this and reading Jeff's mail I implemented it with a
> >>ReturnObjectBag - however, I don't see what that buys me:
> >>
> >>private class MyMockHttpServletRequest extends MockHttpServletRequest {
> >>
> >>     private ReturnObjectBag attributes;
> >>
> >>     public MyMockHttpServletRequest() {
> >>         attributes = new ReturnObjectBag("attributes");
> >>     }
> >>
> >>     public Object getAttribute(String s) {
> >>         return attributes.getHashTable().get(s);
> >>     }
> >>
> >>     public Enumeration getAttributeNames() {
> >>         return attributes.getHashTable().elements();
> >>     }
> >>
> >>     public void setAttribute(String s, Object o) {
> >>         attributes.getHashTable().put(s,o);
> >>     }
> >>}
> >>
> >>Is there a benefit to either approach? Both work perfectly in my test
> >>case and I'm more inclined to go with the first approach just because
> >>it's simpler (and the ReturnObjectBag does nothing for me in this case).
> >>
> >>Cheers,
> >>--Bill
> >>
> >>Jeff Martin wrote:
> >>
> >>>Should probably be a ReturnObjectBag as this lets you setup a list of
> >>>return values for a key.
> >>>
> >>>
> >>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> >>>
> >>>
> >>>>This implementation /is/ a little hazy.
> >>>>
> >>>>The idea is that you should preload your attributes in the order in
> >>>>which they are requested, and then they'll just be returned as the code
> >>>>runs. It's not actually doing a lookup. Checking which attributes are
> >>>>asked for is actually a separate concept and handled by a different
> >>>>expectation. There are some arguments for doing this but it does look a
> >>>>little clumsy.
> >>>>
> >>>>If you don't like this, I suggest you replace this part of the mock
> >>>>request with an ExpectationMap which might be closer to the behaviour
> >>>>you want.
> >>>>
> >>>>S.
> >>>>
> >>>>Bill Lynch wrote:
> >>>>
> >>>>
> >>>>>All,
> >>>>>
> >>>>>I haven't been able to figure out how to set attributes in a
> >>>>>MockHttpServletRequest. I searched the mailing list archives for clues,
> >>>>>but didn't find any (and there's no javadocs for that class!).
> >>>>>
> >>>>>The method that looks like it might work only takes one param:
> >>>>>
> >>>>>request.setupGetAttribute(Object)
> >>>>>
> >>>>>I'd expect that to be
> >>>>>
> >>>>>request.setupGetAttribute(String, Object)
> >>>>>
> >>>>>I've also tried passing in a vector of name/value pairs to that method,
> >>>>>but when I call getAttribute(String) on that request object I get this
> >>>>>error:
> >>>>>
> >>>>>There was 1 failure:
> >>>>>1)
> >>
> >>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError
> > 
> > :
> > 
> >>>>>attributes has run out of objects.
> >>>>>   at
> >>
> >>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:6
> > 
> > 1)
> > 
> >>>>>   at
> >>
> >>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServl
> > 
> > etRequest.java:58)
> > 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/

Re: [MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

Nat et al,

Thanks for the advice - I can change that code (I'm new to the class). I 
have a few more questions:

1) Why should I keep using a ReturnObjectBag as an internal object? In 
my example, does it its use benefit me, or can I use it in a better way?

2) If I shouldn't mess with the internal Hashtable, why is it exposed? 
Seems like poor design then.

3) Any reason there's no Javadocs for any of these classes? :) Having 
better documentation would have steered me away from using the internal 
hashtable probably.

Cheers,
--Bill

Nat Pryce wrote:

> Try using the putObjectToReturn and getNextReturnObject methods rather than
> messing around with the ReturnObjectBag's internal hash table.
> 
> Cheers,
>             Nat.
 >
> ----- Original Message -----
> From: Bill Lynch
> To: <moc...@li...>
> Sent: Thursday, July 17, 2003 2:37 PM
> Subject: Re: [MO-java-users] setting attributes in a mock request
> 
>>Guys,
>>
>>I took Steve's advice and created my own extention to
>>MockHttpServletRequest - my first attempt is below:
>>
>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>
>>     private Hashtable attributes;
>>
>>     public JiveMockHttpServletRequest() {
>>         attributes = new Hashtable();
>>     }
>>
>>     public Object getAttribute(String s) {
>>         return attributes.get(s);
>>     }
>>
>>     public Enumeration getAttributeNames() {
>>         return attributes.elements();
>>     }
>>
>>     public void setAttribute(String s, Object o) {
>>         attributes.put(s,o);
>>     }
>>}
>>
>>After doing this and reading Jeff's mail I implemented it with a
>>ReturnObjectBag - however, I don't see what that buys me:
>>
>>private class MyMockHttpServletRequest extends MockHttpServletRequest {
>>
>>     private ReturnObjectBag attributes;
>>
>>     public MyMockHttpServletRequest() {
>>         attributes = new ReturnObjectBag("attributes");
>>     }
>>
>>     public Object getAttribute(String s) {
>>         return attributes.getHashTable().get(s);
>>     }
>>
>>     public Enumeration getAttributeNames() {
>>         return attributes.getHashTable().elements();
>>     }
>>
>>     public void setAttribute(String s, Object o) {
>>         attributes.getHashTable().put(s,o);
>>     }
>>}
>>
>>Is there a benefit to either approach? Both work perfectly in my test
>>case and I'm more inclined to go with the first approach just because
>>it's simpler (and the ReturnObjectBag does nothing for me in this case).
>>
>>Cheers,
>>--Bill
>>
>>Jeff Martin wrote:
>>
>>>Should probably be a ReturnObjectBag as this lets you setup a list of
>>>return values for a key.
>>>
>>>
>>>On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
>>>
>>>
>>>>This implementation /is/ a little hazy.
>>>>
>>>>The idea is that you should preload your attributes in the order in
>>>>which they are requested, and then they'll just be returned as the code
>>>>runs. It's not actually doing a lookup. Checking which attributes are
>>>>asked for is actually a separate concept and handled by a different
>>>>expectation. There are some arguments for doing this but it does look a
>>>>little clumsy.
>>>>
>>>>If you don't like this, I suggest you replace this part of the mock
>>>>request with an ExpectationMap which might be closer to the behaviour
>>>>you want.
>>>>
>>>>S.
>>>>
>>>>Bill Lynch wrote:
>>>>
>>>>
>>>>>All,
>>>>>
>>>>>I haven't been able to figure out how to set attributes in a
>>>>>MockHttpServletRequest. I searched the mailing list archives for clues,
>>>>>but didn't find any (and there's no javadocs for that class!).
>>>>>
>>>>>The method that looks like it might work only takes one param:
>>>>>
>>>>>request.setupGetAttribute(Object)
>>>>>
>>>>>I'd expect that to be
>>>>>
>>>>>request.setupGetAttribute(String, Object)
>>>>>
>>>>>I've also tried passing in a vector of name/value pairs to that method,
>>>>>but when I call getAttribute(String) on that request object I get this
>>>>>error:
>>>>>
>>>>>There was 1 failure:
>>>>>1)
>>
>>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError
> 
> :
> 
>>>>>attributes has run out of objects.
>>>>>   at
>>
>>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:6
> 
> 1)
> 
>>>>>   at
>>
>>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServl
> 
> etRequest.java:58)
> 

Re: [MO-java-users] setting attributes in a mock request

[Jeff M. <je...@cu...>]

That's amazing. I give up, i've had enough of the request, it's a really
bad API to start with. Might as well get rid of all the servlet mocks
and use the dynamic stuff.

On Thu, 2003-07-17 at 14:37, Bill Lynch wrote:
> Guys,
> 
> I took Steve's advice and created my own extention to 
> MockHttpServletRequest - my first attempt is below:
> 
> private class MyMockHttpServletRequest extends MockHttpServletRequest {
> 
>      private Hashtable attributes;
> 
>      public JiveMockHttpServletRequest() {
>          attributes = new Hashtable();
>      }
> 
>      public Object getAttribute(String s) {
>          return attributes.get(s);
>      }
> 
>      public Enumeration getAttributeNames() {
>          return attributes.elements();
>      }
> 
>      public void setAttribute(String s, Object o) {
>          attributes.put(s,o);
>      }
> }
> 
> After doing this and reading Jeff's mail I implemented it with a 
> ReturnObjectBag - however, I don't see what that buys me:
> 
> private class MyMockHttpServletRequest extends MockHttpServletRequest {
> 
>      private ReturnObjectBag attributes;
> 
>      public MyMockHttpServletRequest() {
>          attributes = new ReturnObjectBag("attributes");
>      }
> 
>      public Object getAttribute(String s) {
>          return attributes.getHashTable().get(s);
>      }
> 
>      public Enumeration getAttributeNames() {
>          return attributes.getHashTable().elements();
>      }
> 
>      public void setAttribute(String s, Object o) {
>          attributes.getHashTable().put(s,o);
>      }
> }
> 
> Is there a benefit to either approach? Both work perfectly in my test 
> case and I'm more inclined to go with the first approach just because 
> it's simpler (and the ReturnObjectBag does nothing for me in this case).
> 
> Cheers,
> --Bill
> 
> Jeff Martin wrote:
> > Should probably be a ReturnObjectBag as this lets you setup a list of
> > return values for a key.
> > 
> > 
> > On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> > 
> >>This implementation /is/ a little hazy.
> >>
> >>The idea is that you should preload your attributes in the order in 
> >>which they are requested, and then they'll just be returned as the code 
> >>runs. It's not actually doing a lookup. Checking which attributes are 
> >>asked for is actually a separate concept and handled by a different 
> >>expectation. There are some arguments for doing this but it does look a 
> >>little clumsy.
> >>
> >>If you don't like this, I suggest you replace this part of the mock 
> >>request with an ExpectationMap which might be closer to the behaviour 
> >>you want.
> >>
> >>S.
> >>
> >>Bill Lynch wrote:
> >>
> >>>All,
> >>>
> >>>I haven't been able to figure out how to set attributes in a 
> >>>MockHttpServletRequest. I searched the mailing list archives for clues, 
> >>>but didn't find any (and there's no javadocs for that class!).
> >>>
> >>>The method that looks like it might work only takes one param:
> >>>
> >>>request.setupGetAttribute(Object)
> >>>
> >>>I'd expect that to be
> >>>
> >>>request.setupGetAttribute(String, Object)
> >>>
> >>>I've also tried passing in a vector of name/value pairs to that method, 
> >>>but when I call getAttribute(String) on that request object I get this 
> >>>error:
> >>>
> >>>There was 1 failure:
> >>>1) 
> >>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
> >>>attributes has run out of objects.
> >>>    at 
> >>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
> >>>    at 
> >>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58) 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/

Re: [MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

Guys,

I took Steve's advice and created my own extention to 
MockHttpServletRequest - my first attempt is below:

private class MyMockHttpServletRequest extends MockHttpServletRequest {

     private Hashtable attributes;

     public JiveMockHttpServletRequest() {
         attributes = new Hashtable();
     }

     public Object getAttribute(String s) {
         return attributes.get(s);
     }

     public Enumeration getAttributeNames() {
         return attributes.elements();
     }

     public void setAttribute(String s, Object o) {
         attributes.put(s,o);
     }
}

After doing this and reading Jeff's mail I implemented it with a 
ReturnObjectBag - however, I don't see what that buys me:

private class MyMockHttpServletRequest extends MockHttpServletRequest {

     private ReturnObjectBag attributes;

     public MyMockHttpServletRequest() {
         attributes = new ReturnObjectBag("attributes");
     }

     public Object getAttribute(String s) {
         return attributes.getHashTable().get(s);
     }

     public Enumeration getAttributeNames() {
         return attributes.getHashTable().elements();
     }

     public void setAttribute(String s, Object o) {
         attributes.getHashTable().put(s,o);
     }
}

Is there a benefit to either approach? Both work perfectly in my test 
case and I'm more inclined to go with the first approach just because 
it's simpler (and the ReturnObjectBag does nothing for me in this case).

Cheers,
--Bill

Jeff Martin wrote:
> Should probably be a ReturnObjectBag as this lets you setup a list of
> return values for a key.
> 
> 
> On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> 
>>This implementation /is/ a little hazy.
>>
>>The idea is that you should preload your attributes in the order in 
>>which they are requested, and then they'll just be returned as the code 
>>runs. It's not actually doing a lookup. Checking which attributes are 
>>asked for is actually a separate concept and handled by a different 
>>expectation. There are some arguments for doing this but it does look a 
>>little clumsy.
>>
>>If you don't like this, I suggest you replace this part of the mock 
>>request with an ExpectationMap which might be closer to the behaviour 
>>you want.
>>
>>S.
>>
>>Bill Lynch wrote:
>>
>>>All,
>>>
>>>I haven't been able to figure out how to set attributes in a 
>>>MockHttpServletRequest. I searched the mailing list archives for clues, 
>>>but didn't find any (and there's no javadocs for that class!).
>>>
>>>The method that looks like it might work only takes one param:
>>>
>>>request.setupGetAttribute(Object)
>>>
>>>I'd expect that to be
>>>
>>>request.setupGetAttribute(String, Object)
>>>
>>>I've also tried passing in a vector of name/value pairs to that method, 
>>>but when I call getAttribute(String) on that request object I get this 
>>>error:
>>>
>>>There was 1 failure:
>>>1) 
>>>testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
>>>attributes has run out of objects.
>>>    at 
>>>com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
>>>    at 
>>>com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58) 

Re: [MO-java-users] setting attributes in a mock request

[Jeff M. <je...@cu...>]

Should probably be a ReturnObjectBag as this lets you setup a list of
return values for a key.


On Thu, 2003-07-17 at 08:47, Steve Freeman wrote:
> This implementation /is/ a little hazy.
> 
> The idea is that you should preload your attributes in the order in 
> which they are requested, and then they'll just be returned as the code 
> runs. It's not actually doing a lookup. Checking which attributes are 
> asked for is actually a separate concept and handled by a different 
> expectation. There are some arguments for doing this but it does look a 
> little clumsy.
> 
> If you don't like this, I suggest you replace this part of the mock 
> request with an ExpectationMap which might be closer to the behaviour 
> you want.
> 
> S.
> 
> Bill Lynch wrote:
> > All,
> > 
> > I haven't been able to figure out how to set attributes in a 
> > MockHttpServletRequest. I searched the mailing list archives for clues, 
> > but didn't find any (and there's no javadocs for that class!).
> > 
> > The method that looks like it might work only takes one param:
> > 
> > request.setupGetAttribute(Object)
> > 
> > I'd expect that to be
> > 
> > request.setupGetAttribute(String, Object)
> > 
> > I've also tried passing in a vector of name/value pairs to that method, 
> > but when I call getAttribute(String) on that request object I get this 
> > error:
> > 
> > There was 1 failure:
> > 1) 
> > testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
> > attributes has run out of objects.
> >     at 
> > com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
> >     at 
> > com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58) 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
Jeff Martin

Memetic Engineer

http://www.custommonkey.org/

RE: [MO-java-users] setting attributes in a mock request

[<Ext...@no...>]

Steve,

> This implementation /is/ a little hazy.
>=20
> The idea is that you should preload your attributes in the order in=20
> which they are requested, and then they'll just be returned=20
> as the code=20
> runs. It's not actually doing a lookup. Checking which attributes are=20
> asked for is actually a separate concept and handled by a different=20
> expectation. There are some arguments for doing this but it=20
> does look a=20
> little clumsy.

What are the arguments for this approach?  I encountered the same =
problem a while back and I'm still scratching my head :-)

Thanks,
Mike

Re: [MO-java-users] setting attributes in a mock request

[Steve F. <st...@m3...>]

This implementation /is/ a little hazy.

The idea is that you should preload your attributes in the order in 
which they are requested, and then they'll just be returned as the code 
runs. It's not actually doing a lookup. Checking which attributes are 
asked for is actually a separate concept and handled by a different 
expectation. There are some arguments for doing this but it does look a 
little clumsy.

If you don't like this, I suggest you replace this part of the mock 
request with an ExpectationMap which might be closer to the behaviour 
you want.

S.

Bill Lynch wrote:
> All,
> 
> I haven't been able to figure out how to set attributes in a 
> MockHttpServletRequest. I searched the mailing list archives for clues, 
> but didn't find any (and there's no javadocs for that class!).
> 
> The method that looks like it might work only takes one param:
> 
> request.setupGetAttribute(Object)
> 
> I'd expect that to be
> 
> request.setupGetAttribute(String, Object)
> 
> I've also tried passing in a vector of name/value pairs to that method, 
> but when I call getAttribute(String) on that request object I get this 
> error:
> 
> There was 1 failure:
> 1) 
> testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
> attributes has run out of objects.
>     at 
> com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
>     at 
> com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58) 

[MO-java-users] setting attributes in a mock request

[Bill L. <bi...@ji...>]

All,

I haven't been able to figure out how to set attributes in a 
MockHttpServletRequest. I searched the mailing list archives for clues, but 
didn't find any (and there's no javadocs for that class!).

The method that looks like it might work only takes one param:

request.setupGetAttribute(Object)

I'd expect that to be

request.setupGetAttribute(String, Object)

I've also tried passing in a vector of name/value pairs to that method, but when 
I call getAttribute(String) on that request object I get this error:

There was 1 failure:
1) testGetAttribute(com.foo.util.MyTest)junit.framework.AssertionFailedError: 
attributes has run out of objects.
	at com.mockobjects.ReturnObjectList.nextReturnObject(ReturnObjectList.java:61)
	at 
com.mockobjects.servlet.MockHttpServletRequest.getAttribute(MockHttpServletRequest.java:58)


Thanks in advance,
--Bill

RE: [MO-java-users] Modifying method parameters with DynaMock

[<Ext...@no...>]

Nathaniel, thanks very much - I can almost cut'n'paste the code :-)

> -----Original Message-----
> From: ext Nat Pryce [mailto:nat...@b1...]
> Sent: 02 July, 2003 18:02
> To: Hogan Mike (EXT-IBM/Espoo);
> moc...@li...
> Subject: Re: [MO-java-users] Modifying method parameters with DynaMock
>=20
>=20
> The Callable interface and the decorator/stub structure is designed to
> achieve exactly what you need.  If you want to mock a=20
> side-effect, create a
> decorator chain with a domain-specific stub that implements=20
> the side effect.
> It is easy to write the stub as an anonymous inner class in=20
> the body of the
> test, and then later extract it into a reusable class if you=20
> need it in more
> than one test.
>=20
> For example, in long-hand using the version 0.09 API:
>=20
> // Note: resultSetHandler and resultSet are final so they can=20
> be used by
> // the anonymous inner class
> final ResultSetHandler resultSetHandler =3D ....
> final Mock mockResultSet =3D new Mock(ResultSet.class);
>=20
> Mock mockSQLExecuter =3D new Mock(SQLExecuter.class);
>=20
> mockSQLExecuter.add(
>     new CallOnceExpectation(
>     new CallSignature( "execute", C.eq(  expectedSQL,=20
> expectedBindVariables,
> resultSetHandler ) ),
>     new VoidStub() {
>         public void getDescription() { " [calls back to
> resultSetHandler]"; }
>         public Object call( String methodName, Object[] args ) {
>             resultSetHandler.handle(=20
> (ResultSet)mockResultSet.proxy() );
>             return super.call( methodName, args ); // stubs=20
> the void result
>         }
>     } ) ) );
>=20
> In my experimental branch I have added an expect method to my=20
> branch that
> takes three parameters: a method name, argument constraints=20
> and a Callable
> stub.  This creates the CallOnceExpectation, NameMatcher,=20
> ArgumentMatcher
> around the stub, and so makes it more convenient to use=20
> domain-specific
> stubs in tests.
>=20
> I have also put some documentation about these=20
> interfaces/classes on the
> Mock Objects wiki, so check that out for more info.
>=20
> Regards,
>             Nat.
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
>=20
> ----- Original Message -----
> From: <Ext...@no...>
> To: <moc...@li...>
> Sent: Wednesday, July 02, 2003 3:25 PM
> Subject: [MO-java-users] Modifying method parameters with DynaMock
>=20
>=20
> Hi,
>=20
> I want to "do something" with a parameter that is passed into=20
> a method that
> I am DynaMock'ing.  The interface is:
>=20
> public interface SqlExecutor {
>     public void execute(String sql, Iterator bindVariables,=20
> ResultSetHandler
> handler) throws SQLException;
> }
>=20
> and
>=20
> public interface ResultSetHandler {
>     public void handle(ResultSet resultSet) throws SQLException;
> }
>=20
> So, I create a DynaMock of SqlExecutor, my code under test=20
> passes in some
> implementation of ResultSetHandler, and I need the DynaMock to push a
> ResultSet into this ResultSetHandler implementation.
>=20
> Can DynaMock do this, or should I fall back on plain old=20
> expectation classes
> etc?
>=20
> Thanks,
> Mike.
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_06
1203_01/01
_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users



-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

Re: [MO-java-users] Modifying method parameters with DynaMock

[Nat P. <nat...@b1...>]

The Callable interface and the decorator/stub structure is designed to
achieve exactly what you need.  If you want to mock a side-effect, create a
decorator chain with a domain-specific stub that implements the side effect.
It is easy to write the stub as an anonymous inner class in the body of the
test, and then later extract it into a reusable class if you need it in more
than one test.

For example, in long-hand using the version 0.09 API:

// Note: resultSetHandler and resultSet are final so they can be used by
// the anonymous inner class
final ResultSetHandler resultSetHandler = ....
final Mock mockResultSet = new Mock(ResultSet.class);

Mock mockSQLExecuter = new Mock(SQLExecuter.class);

mockSQLExecuter.add(
    new CallOnceExpectation(
    new CallSignature( "execute", C.eq(  expectedSQL, expectedBindVariables,
resultSetHandler ) ),
    new VoidStub() {
        public void getDescription() { " [calls back to
resultSetHandler]"; }
        public Object call( String methodName, Object[] args ) {
            resultSetHandler.handle( (ResultSet)mockResultSet.proxy() );
            return super.call( methodName, args ); // stubs the void result
        }
    } ) ) );

In my experimental branch I have added an expect method to my branch that
takes three parameters: a method name, argument constraints and a Callable
stub.  This creates the CallOnceExpectation, NameMatcher, ArgumentMatcher
around the stub, and so makes it more convenient to use domain-specific
stubs in tests.

I have also put some documentation about these interfaces/classes on the
Mock Objects wiki, so check that out for more info.

Regards,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: <Ext...@no...>
To: <moc...@li...>
Sent: Wednesday, July 02, 2003 3:25 PM
Subject: [MO-java-users] Modifying method parameters with DynaMock


Hi,

I want to "do something" with a parameter that is passed into a method that
I am DynaMock'ing.  The interface is:

public interface SqlExecutor {
    public void execute(String sql, Iterator bindVariables, ResultSetHandler
handler) throws SQLException;
}

and

public interface ResultSetHandler {
    public void handle(ResultSet resultSet) throws SQLException;
}

So, I create a DynaMock of SqlExecutor, my code under test passes in some
implementation of ResultSetHandler, and I need the DynaMock to push a
ResultSet into this ResultSetHandler implementation.

Can DynaMock do this, or should I fall back on plain old expectation classes
etc?

Thanks,
Mike.


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

[MO-java-users] Modifying method parameters with DynaMock

[<Ext...@no...>]

Hi,

I want to "do something" with a parameter that is passed into a method =
that I am DynaMock'ing.  The interface is:

public interface SqlExecutor {
    public void execute(String sql, Iterator bindVariables, =
ResultSetHandler handler) throws SQLException;
}

and

public interface ResultSetHandler {
    public void handle(ResultSet resultSet) throws SQLException;
}

So, I create a DynaMock of SqlExecutor, my code under test passes in =
some implementation of ResultSetHandler, and I need the DynaMock to push =
a ResultSet into this ResultSetHandler implementation.

Can DynaMock do this, or should I fall back on plain old expectation =
classes etc?

Thanks,
Mike.

Re: [MO-java-users] Problem with SimpleServletTest in wiki

[Lucas F. <luc...@gm...>]

Nat Pryce wrote:
> It's a bug in the test.  I've changed the version on the Wiki (but not ran
> it yet) so try copy/pasting it again.
> 


by chance I tried the same last weekend and made the same correction.
I wanted to mention it today...

Lucas

Re: [MO-java-users] Problem with SimpleServletTest in wiki

[<joh...@sa...>]

Nat,

Thanks for the reply. I've added my solution to the example on the wiki. Hope
you don't mind :) I just figured it could save someone new to this the trouble.

Thanks again,
John

Quoting Nat Pryce <nat...@b1...>:

> It's a bug in the test.  I've changed the version on the Wiki (but not ran
> it yet) so try copy/pasting it again.
> 
> Cheers,
>             Nat.
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
> 
> ----- Original Message -----
> From: <joh...@sa...>
> To: <moc...@li...>
> Sent: Tuesday, July 01, 2003 3:00 PM
> Subject: [MO-java-users] Problem with SimpleServletTest in wiki
> 
> 
> > Hi everyone.
> >
> > I just started playing around with the new DynamicMockObjects in version
> 0.09. I
> > litereally copied and pasted the example on this page:
> >
> > http://www.mockobjects.com/wiki/SimpleServletTest
> >
> > And then wrote an implementation of SimpleCalcServlet. I kept the
> implementation
> > very simple, and this is what it looks like:
> >
> > private void process(HttpServletRequest request, HttpServletResponse
> response)
> > throws ServletException, IOException {
> > Integer a = Integer.decode(request.getParameter("a"));
> > Integer b = Integer.decode(request.getParameter("b"));
> >
> > int result = a.intValue() + b.intValue();
> > response.setContentType("text/html");
> >
> > PrintWriter out = response.getWriter();
> > out.print("Result = " + result);
> > }
> >
> > Now the test runs, verify works just fine. But the assertEquals() call in
> the
> > SimpleServletTest fails with this message:
> >
> > Output should be an addition expected:<Result = 7> but
> > was:<java.io.PrintWriter@fa7e74>
> >
> > Now it's obvious what the problem is. The question is, is it something I
> am
> > doing wrong or a bug?
> >
> > Many thanks,
> > John
> >
> >
> >
> > -------------------------------------------------
> > "Modernizing Business Processes Through Proven IT Solutions"
> > http://www.sapiens.com/
> >
> >
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> > Data Reports, E-commerce, Portals, and Forums are available now.
> > Download today and enter to win an XBOX or Visual Studio .NET.
> > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> > _______________________________________________
> > Mockobjects-java-users mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 



-------------------------------------------------
"Modernizing Business Processes Through Proven IT Solutions"
http://www.sapiens.com/ 

Re: [MO-java-users] Problem with SimpleServletTest in wiki

[Nat P. <nat...@b1...>]

It's a bug in the test.  I've changed the version on the Wiki (but not ran
it yet) so try copy/pasting it again.

Cheers,
            Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661

----- Original Message -----
From: <joh...@sa...>
To: <moc...@li...>
Sent: Tuesday, July 01, 2003 3:00 PM
Subject: [MO-java-users] Problem with SimpleServletTest in wiki


> Hi everyone.
>
> I just started playing around with the new DynamicMockObjects in version
0.09. I
> litereally copied and pasted the example on this page:
>
> http://www.mockobjects.com/wiki/SimpleServletTest
>
> And then wrote an implementation of SimpleCalcServlet. I kept the
implementation
> very simple, and this is what it looks like:
>
> private void process(HttpServletRequest request, HttpServletResponse
response)
> throws ServletException, IOException {
> Integer a = Integer.decode(request.getParameter("a"));
> Integer b = Integer.decode(request.getParameter("b"));
>
> int result = a.intValue() + b.intValue();
> response.setContentType("text/html");
>
> PrintWriter out = response.getWriter();
> out.print("Result = " + result);
> }
>
> Now the test runs, verify works just fine. But the assertEquals() call in
the
> SimpleServletTest fails with this message:
>
> Output should be an addition expected:<Result = 7> but
> was:<java.io.PrintWriter@fa7e74>
>
> Now it's obvious what the problem is. The question is, is it something I
am
> doing wrong or a bug?
>
> Many thanks,
> John
>
>
>
> -------------------------------------------------
> "Modernizing Business Processes Through Proven IT Solutions"
> http://www.sapiens.com/
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

[MO-java-users] Problem with SimpleServletTest in wiki

[<joh...@sa...>]

Hi everyone.

I just started playing around with the new DynamicMockObjects in version 0.09. I
litereally copied and pasted the example on this page:

http://www.mockobjects.com/wiki/SimpleServletTest

And then wrote an implementation of SimpleCalcServlet. I kept the implementation
very simple, and this is what it looks like:

private void process(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
Integer a = Integer.decode(request.getParameter("a"));
Integer b = Integer.decode(request.getParameter("b"));

int result = a.intValue() + b.intValue();
response.setContentType("text/html");

PrintWriter out = response.getWriter();
out.print("Result = " + result);
}

Now the test runs, verify works just fine. But the assertEquals() call in the
SimpleServletTest fails with this message:

Output should be an addition expected:<Result = 7> but
was:<java.io.PrintWriter@fa7e74>

Now it's obvious what the problem is. The question is, is it something I am
doing wrong or a bug?

Many thanks,
John



-------------------------------------------------
"Modernizing Business Processes Through Proven IT Solutions"
http://www.sapiens.com/