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

Reply via email to