Use mock objects. www.mockobjects.com To use the automated mock object creator may require modifying the code a little (creating some more interfaces), but you can simply use the concept. It is the only great way to test complicated failure cases, especially when there is a complicated state that has to be established.
The idea is to have an object that you can tell it what "state" to be in - for instance, to fail whenever you call a certain routine, etc, and what kind of failure. It implements the same interface as the real object, so that you can use it interchangeably. There are some other concepts with mockobjects also, such as input or call validation - the object can keep track of how it was called and with what parameters and in what order. This can all be validated against your expectations. the mock objects people call it "endotesting" because you are testing from the inside, but without tainting your actual code with any knowledge of the testing framework. (Besides the need to create an interface based on the object, which is a sometimes a good thing anyway, though it does add one more file to maintain). Pretty good stuff... Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., the leading provider of Net services software. >>> Loren Rosen <[EMAIL PROTECTED]> 11/15/01 3:27:44 PM >>> Hiram Chirino wrote: > Hi Loren! > > >From: Loren Rosen <[EMAIL PROTECTED]> > >To: "[EMAIL PROTECTED]" > ><[EMAIL PROTECTED]> > >Subject: [JBoss-dev] jbossmq: persistance implementation questions > >Date: Mon, 12 Nov 2001 20:22:27 -0800 > > > > > >* Performance tuning/scalability: has any work been done to address > >potential bottlenecks for high message throughput, large numbers of > >queues or topics, etc.? > > > > Work has gone into making reading/writing from storage more efficient. I > don't think we have profiled the system enough yet to find out where the > bottle necks are. A good first step would be to measure the single producer/consumer latency, and tune that. Low latency is a important goal in its own right, and moreover if the CPU overhead is too high you won't even be able to keep the disk busy writing messages. I can go ahead and do this. > > > >* recovery robustness: recovery is a tricky thing since there's so many > >possible ways things can fail. What's been done to think > >about/test-for/defend-against all the possibilities? > > > > Basic recovery test have been succeeding. It's hard to automate failure > testing. More code review would be good in this area to see if we are > missing anything. I'll look through the code more closely. But recovery is testable. What you have to do is create some corrupt data files (probably by using a byte-level editor to munge some existing data files). Then you need some scripts to start up the server with those files -- which doesn't fit so well with a pure-Java Junit-based test suite. (You could also create the files by making versions of the server which quit at various awkward places.) What this won't test so easily is recovery from failures during recovery. > Regards, > Hiram > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development