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 |