Menu
▾
▴
RE: [MO-java-dev] Common test cases
|
From: Jeff M. <je...@cu...> - 2002-06-21 19:19:21
|
Hmm, not sure about this. We've got some reasonably complex servlets and
some really nasty filters (result of not refactoring properly) and so
far we've been able to to test them using mocks. It could be of course
that our tests aren't very good and that might be some of it, but I
don't see that a servlet should become that complex that it cannot be
tested with mocks.
I'm curious to know what your actually doing and where the mocks start
to fail you. So far they're implementation has been driven by my
specific needs. I've consciously not implemented and method which I'm
not using and trying to do the minimum necessary to implement it. This
means that if I only call a method once in my code it will only support
returning one value. It could be that other people need to be able to
setup list of objects (ReturnObjectList) or some other method. This
might be enough to resolve your problems.
It could be that there's a whole different level of problems I've not
come across yet in which case I'm no longer qualified to comment on an
appropriate testing method.
One thing I've found so far though is that complexity has been a failing
of my abilities not something that was an inherent property of the
problem I was trying to solve, so maybe trying to use mocks will present
a different approach.
Either way it would be cool if you could give us a bit more info.
Right I'm off home for the weekend. See you all on Monday ttfn.
On Fri, 2002-06-21 at 18:35, Trenton Lipscomb wrote:
> Basically, I think ServletContext and ServletConfig need some real functionality. Because of this, it precludes them from being a mock. They need real functionality because it's not sufficient to simply test that a servlet calls methods on a MockServletContext, or that it sets the proper attributes. I think you actually need real functionality here, in order to have the servlet progress far enough along its execution path to make testing useful.
>
> This is certainly true for anything we tried to do for ServletConfig. I frequtly do a lot of setup within my init(ServletConfig) method, and without a real ServletConfig, I can't get the servlet to a point where doing any tests on it are meaningful. I need a real config so that the servlet can init properly. Then, I can test it using MockServletRequests and Responses.
>
> *trenton
>
> -----Original Message-----
> From: Jeff Martin [mailto:je...@mk...]
> Sent: Friday, June 21, 2002 10:00 AM
> To: MockObjects
> Subject: RE: [MO-java-dev] Common test cases
>
>
> Sorry, not quite sure I understand.
>
> My intent for the standard test cases was just to start a by having a
> commonly use set of objects.
>
> e.g.
>
> protected final MockHttpRequest request = new MockHttpRequest();
> protected final MockHttpResponse response = new MockHttpResponse();
> protected final MockServletContext context = new MockServletContext();
>
> ...
>
> protected void setUp(){
> request.setupGetServletContext(context);
> }
>
> ...
>
> protected void verify(){
> request.verify();
> response.verify();
> context.verify();
> }
>
> That kinda thing.
>
> On Wed, 2002-06-19 at 22:18, Trenton Lipscomb wrote:
> > Yes, and just to be clear, these should be partial (or even full) implementations of the interfaces. These won't be mocks, since we'll actually need the classes to fill their role and relay configuration data to the servlet.
> >
> > *trenton
> >
> > -----Original Message-----
> > From: Vincent Massol [mailto:vm...@oc...]
> > Sent: Wednesday, June 19, 2002 12:33 PM
> > To: Moc...@li...
> > Subject: RE: [MO-java-dev] Common test cases
> >
> >
> > +1
> >
> > We need to make sure they are still quite generic though.
> >
> > -Vincent
> >
> > > -----Original Message-----
> > > From: moc...@li...
> > > [mailto:moc...@li...] On Behalf Of
> > > Jeff Martin
> > > Sent: 19 June 2002 16:48
> > > To: MockObjects
> > > Subject: [MO-java-dev] Common test cases
> > >
> > > I've been starting to thing that it might be nice to have some
> > abstract
> > > test cases which perform common and boring setup of mock objects.
> > >
> > > Like setting up servlet requests and all those context type stuff.
> > >
> > > Thoughts/objects?
> > > --
> > > Jeff Martin
> > >
> > > Memetic Engineer
> > >
> > > http://www.custommonkey.org/
> > >
> > >
> > >
> > ------------------------------------------------------------------------
> > --
> > > --
> > > Bringing you mounds of caffeinated joy
> > > >>> http://thinkgeek.com/sf <<<
> > >
> > > _______________________________________________
> > > Mockobjects-java-dev mailing list
> > > Moc...@li...
> > > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> >
> > ----------------------------------------------------------------------------
> > Bringing you mounds of caffeinated joy
> > >>> http://thinkgeek.com/sf <<<
> >
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> > ----------------------------------------------------------------------------
> > Bringing you mounds of caffeinated joy
> > >>> http://thinkgeek.com/sf <<<
> >
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> --
>
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
--
Jeff Martin
Memetic Engineer
http://www.custommonkey.org/
|
