|
From: Nat P. <nat...@b1...> - 2003-07-17 15:54:06
|
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
|