Re: [MO-java-users] MockHttpServlet, CheckImmediateValues

[Jeff D. <Jef...@no...>]

Jeff Martin wrote:

> On Thu, 2003-05-01 at 22:04, Jeff Duska wrote:
> > I don't see how MockHttpServlet.getAttribute can work correctly when
> > setAttribute and the getAttribute looking at different collections. This
> > will work fine, if you only plan to set an Attribute or get an
> > Attribute. In my case, I'm chaining two objects implementing a command
> > pattern together. The first command sets some attributes with the
> > standard setAttribute() , but when the next command tries to use
> > getAttribute(). This will call myAttributeValues.getNextReturnObject(),
> > but setAttribute appeared to use myAttributes.addActual(new
> > MapEntry(aKey, aValue)). I don't see how it will find my attribute ever
> > in the second command. It would seem to me that needs to update both of
> > these collections, so the getAttributes would work correctly.

> The problem is how do I know which collection I should be using when.
> When does getAttribute return an object from setAttribute and when does
> it return one from setupGetAttribute?
>

I think, I'm still fishing in the code,  that I would expect that getAttribute
to see setting in both setupGetAttribute and setAttribute. What I would do
different is have setAttribute add to both the myAttributes ExepctationSet and
myAttributes ReturnObjectBag. This way the expections would still fire on
wrong attributes, but the getAttribute would still work for the chained
servlets tests. The only reason this would work, if you need to or wanted to
track what the setupGetAttributes were. In this case, you'd need a new
collection for only setup Attributes.

I'm sure you thinking to yourself chained servlet? That not following TDD
correctly. I should be only test the one servlet. This is true, but right now
my design it a little brittle in that regard. I cannot change in this phase. I
will most likely move this to Struts in the next phase to resolve issues like
this.


> The way I get around this is to make sure setupGetAttribute has all the
> objects that I expect setAttribute to set. I should know this as I will
> be setting up setExpectedAttribute.

Basicly, I end up with something like this

setupGetAttribute(IUser,USER_KEY, user); //  need for getAttribute to work -
adds to myAttributeValues
setAttribute(IUser,USER_KEY, user);          // need to pass ExpectionTests
- adds to myActualItems

The only reason I don't like this is that somewhat confusing to a new user. I
expect that new developer will miss this step. The other option is to remove
the execptation, but this would imply that I don't expect the user to be in
the session. Since the point of unit test is to provide documenation, this
doesn't seem like a good idea.

> To be honest I really try and avoid using attributes as they're really
> open to abuse. I use a single CustomSession object which contains all
> the in scope objects I'm using. So get/setAttribute is something I
> descourage from my projects.
>

This sounds quite intresting. Do you have an example that might be able to
share?

>
> >
> > Next, I not sure I that getAttribute should use getNetReturnObject,
> > because it appears to requires that the attribute be in the collection.
> > In my usage of the HttpSession, I have a couple places where I test for
> > the existence of the attribute like this
> > (_session.getAttributte("mykey")==null). This will not work, because it
> > will fire off an exception due to the attribute not existing in the
> > myAttributte ReturnObjectBag.
>
> session.setupGetAttribute(null);
>

There was CheckImmediateValue. I'm curious how do you use that in the process?
I'm also curious if is better to use the specific libraries like these or the
dynamic libraries using Mock proxy stuff.

Intresting. I would have never thought to do that.

Thanks for all the help

Regards,

Jeff Duska