This one time, at band camp, Jeffrey Bonevich said: JB>Posted example code on the wiki: JB> JB>http://www.brainopolis.com/castorwiki/Wiki.jsp?page=CastorMockObjects JB> JB>jeff JB> JB>>>> [EMAIL PROTECTED] 12/03/03 01:31PM >>> JB>Figured out the answer to my own question: JB> JB>CastorJDO cacheing is getting in the way of the mock object JB>expectations, in that because the same object was earlier loaded by JB>Castor into the same JVM as a different unit test, the second test does JB> JB>not actually change the MockPreparedStatement expectation for result JB>sets returned. Solutions to this problem include: JB> JB>* run each unit test in its own JVM (probably the most realistic) JB>* set cache-type type="none" in the mapping.xml file (I did this and it JB> JB>worked) JB>* have each unit test load a unique object so that cacheing collisions JB> JB>do not occur JB>* account for cacheing as part of unit testing (smacks more of JB>integration testing at this point, and it would be very difficult to do JB>in a consistent, simple manner)
Jeff, There is one other solution that is not mentioned above. Make use of the cache eviction API to purge the cache of objects so that the tests are self-contained. See the following for more details: http://www.castor.org/javadoc/org/exolab/castor/jdo/Database.html#expireCache(java.lang.Class[],%20java.lang.Object[]) Bruce -- perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");' The Castor Project http://www.castor.org/ Apache Geronimo http://incubator.apache.org/projects/geronimo.html ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
