Can mockobjects be integrated with JUnit? --jason
On Thu, 15 Nov 2001, Jeff Tulley wrote: > 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 > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
