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 |