|
From: Jeff M. <je...@mk...> - 2002-08-23 14:55:11
|
It's something we've been thinking about. Another example is testing
servlets.
To run a servlet you need a number of objects request, response,
session, context, request dispatcher... With tags there's even more. I
started use some a common testcase for these which populates variables
with these mocks and sets up the relationships between them.
I think now my approach would be to have a test helper class which has
these objects in it.
public void testSomeServlet(){
SomeServlet someServlet =3D new SomeServlet();
ServletTestHelper testHelper =3D new ServletTestHelper();
testHelper.getRequest().setExpectedGetParameter("something");
testHelper.getSession()...
testHelper.testInitServlet(servlet);
testHelper.testDoPost(servlet);
testHelper().getRequest().verify();
testHelper().getSession().verify();
}
It's not necessarily clever or going to cover all cases but it's a help.
JDBC stuff might be a bit more difficult because there's more ways in
which it can be used.
On Fri, 2002-08-23 at 14:44, Gilles DODINET wrote:
> im really sorry about the previous post. this is the right one. could the=
moderator please delete the previous one ?
>=20
>=20
> ---- Message starts here ---
>=20
> no, thats not what i mean : my MockConnection is a
> MockConnection just as it is now. Although my
> MockConnectionFactory would create the
> MockPreparedStatement and the MockPreparedStatementFactory
> would create the MockResultSet. calling verify on
> myMockConnection would call verify myMockPreparedStatement
> which in turn would verify myMockResultSet. the goal under
> the request is to statically describe a reusable test
> configuration, i.e. describe the configuration of mock
> components in a xml file - in a kilim way
> (http://www.objectweb.org/kilim). so instead of creating
> and configuring MockObjects directly in the TestCase i
> would delegate creation and configuration through a call of
> type myMockConnection =3D
> myConnectionFactory.getConnection("MockConnectionThatBehaves
> LikeThat"); and i wouldnt worry about instantiating or
> configuring neither the MockResultSet nor the
> MockPreparedStatement anymore.
> i think this is relevant since behaviour is often shared.
> This could allow me to call the verify method *just* on
> myMockConnection.
> that approach is arguable, like i said in my previous post,
> since it implies that the TestCase lost a bit of control
> upon the test environment configuration. however i have the
> intuition that it would be of much help. And also even if
> you dont agree with the cascading verify idea, perhaps you
> would with the factory one (i found kilim to be very
> useful) ? anyway im always interested in your point of
> view.
>=20
> thanks for your reply,
>=20
> -- gd
>=20
>=20
> >Messsage du 23/08/2002 12:30
> >De : Nat Pryce <nat...@b1...>
> >A : Gilles DODINET <rh...@wa...>
> >Copie =E0 :
> >Objet : Re: [Mockobjects-java-users] Feature-request=20
> >
> > If I understand you, you want your MockConnection to
> create your
> > MockPreparedStatement and MockResultSet objects. I think
> that's the
> > wrong approach because you are putting too much real
> implementation into
> > your mock objects.
> >
> > Instead, create a MockConnection a MockPreparedStatement,
> keep
> > references both objects in variables in your test, tell
> the connection
> > to return the mock statement when createStatement() (or
> whatever) is
> > called, and verify both objects at the end of the test.
> >
> > Cheers,
> > Nat.
> >
> > On Fri, 2002-08-23 at 12:00, Gilles DODINET wrote:
> > > Hi,
> > >
> > > I think MockObjects are missing a feature very useful
> when working with factories. imho they should follow the
> Composite pattern. For instance, let's say i wanna use a
> MockConnection : i need a MockPreparedStatement and a
> MockResultset as well. If i want to externalize the
> creation of my MockObjects from the TestCase perspective
> (ok thats perhaps arguable), i have no practical way to do
> it, since i will have to call verify() on both
> myMockPreparedStatement and myMockResultset as well. But
> since the creation of the MockObject was delegated, i lost
> the references to those objects (and also
> Verifier.verifyObject() doesnt verify myPreparedStatement :
> it just ensure that it has been used).
> > > There's also a crappy work-around : using AspectJ, we
> can these functionnality at the price of extending
> MockConnection, MockPreparedStatement and MockResultSet.
> thats not satisfactory tho. so the better way i think would
> be to modify MockObject class to make it composite. What do
> you think of this ?
> > >
> > > -- gd
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: OSDN - Tired of that
> same old
> > > cell phone? Get a new here for FREE!
> > >
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs339
> 0
> > >
> > > Mockobjects-java-users mailing list
> > > Moc...@li...
> > >
> https://lists.sourceforge.net/lists/listinfo/mockobjects-jav
> a-users
> > --
> > Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
> > Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
> > http://www.b13media.com
> >
> >
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone? Get a new here for FREE!
> https://www.inphonic.com/r.asp?r_________________________________________=
______
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
--=20
jeff martin
information technologist
mkodo limited
mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...
www.mkodo.com
|