Re: [MO-java-dev] verify()ing object hierachies.

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

One problem you might come across is circular verifications. It's a
problem we had here where you can add a statement to a connection and
then the connection to the statement. When you call verify the whole
thing goes into a loop.

The way to get around it is probably to change verify to build up a
verification set by adding it's children to it and then verifying
everything in the set.

You may not hit this problem but it's possible that these sort of
changes would increase the chances of it happening.


On Fri, 2002-09-13 at 10:01, Simon Levitt wrote:
> On Friday 13 September 2002 00:07, Steve Freeman wrote:
> > I'd like to see some concrete examples, especially for ExpectationMap
> > which is, itself a verifiable. It's sounds like some of your tests may
> > be going too deep. You can overspecify, as well as underspecify.
> >
> Concrete example:
> 
> We've got our own JDBC Connection Pool implementation which like most has 
> a finite set of actual JDBC Connections that it can allocate to threads. 
> 
> Each piece of code wanting to use JDBC talks directly to the Pool asking 
> for a connection to a particular named databaase (through a symbolic 
> name). 
> 
> Thus the call to the Connection Pooling classes is performed within the 
> method we want to test.
> 
> e.g:
> 
> public Person getPerson(String name) {
> 	// PooledConnection is a wrapper round Connection
> 	PooledConnection conn = ConnectionPool.getPooledConnection("persondb");
> 
> 	try {
> 		conn.enable(); // Actually gets JDBC Connection from pool
> 		stmt = conn.prepareStatement(...);
> 
> 		results = stmt.exeuteQuery();
> 		person = new Person(results):
> 	}
> 	catch (SQLException e) {
> 		conn.disable();
> 	}
> 	reutrn person;
> }
> 
> I've developed a Mocked version of the Connection Pooling system to allow 
> these methods to be tested. 
> 
> What happens is the setup calls on MockConnectionPool populate an 
> ExpectationMap from pool name to MockPooledConnection - so you can test 
> the expectation that certain database connections will be/are being used. 
> verify() is checking expected keys vs actual keys.
> 
> What I'd like to automate is the verification of the expectations set on 
> the MockPooledConnection objects contained in the ExpectationMap (ie. its 
> values). 
> 
> I think it would also be useful to check the MockStatements contained 
> therein, and their MockResultSets as well. 
> 
> You can obviously manually do this at the moment however verifying the 
> expectations means keeping a lot of object references locally to the test 
> method for the duration of the whole test.
> 
> Simon.,
> -- 
> --------------------------------------------------------------------------
>          Simon Levitt, Senior Development Engineer @ WorldPay plc,
> WorldPay Centre, The Science Park, Milton Rd., Cambridge, CB4 0WE, ENGLAND  
>  Sim...@uk...   Ph:+44(0)1223 715151  F:+44(0)1223 715157
> ------------------------- http://www.worldpay.com/ -----------------------
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com