mockobjects-java-users

[Mockobjects-java-users] Re : Feature-Request

[Gilles D. <rh...@wa...>]

im really sorry about the previous post. this is the right one. could the =
moderator please  delete the previous one =3F


---- Message starts here ---

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) =3F anyway im always interested in your point of
view.

thanks for your reply,

-- gd


>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 
>
> 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 =3F
> >
> > -- gd
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that
same old
> > cell phone=3F Get a new here for FREE!
> >
https://www.inphonic.com/r.asp=3Fr=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
>
>
>

Re: [Mockobjects-java-users] Re : Feature-Request

[Jeff M. <je...@mk...>]

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