Right, deep testing of service internals does not really belong in the current jbosstest unit tests. Those are for testing client oriented interaction with the server. Each module should have its own unit tests for internal testing. Transaction failure semantics and recovery is getting to in between ground. You could do as Jeff suggested and make use of mock objects to deploy different version of the mq and other JBoss services to isolate the testing in either unit testsuite.
----- Original Message ----- From: "Jason Dillon" <[EMAIL PROTECTED]> To: "Hiram Chirino" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, November 15, 2001 4:29 PM Subject: Re: [JBoss-dev] jbossmq: persistence implementation questions > I was only really suggesting that rather than test the entire JBoss server > instance with a JBoss service, to focus on the individual component which > performs this functionality. > > Assuming that the component can be started up from inside JUnit, then we can > setup any given environment and given it a whirl. The same could be done by > testing the entire server, but it would be more complicated and would not > tell you that the given component will pass or fail the test (another > component could be causing the component to fail... which is useful to know > too). > > In this case, you could setup a log which might have 3 valid and then > invalid garbage. JUnit could setup a log file which looked like this, then > startup the component with that generated file and see if it performs as > desired. > > Todo the same would mean knowing more about how the server starts up, its > config and such to doctor up the environment to make the test work. > > Anyways, I am no QA/Unit Test expert... though work has kinda given me that > hat to put on now (those bastards), so this is mostly specilation on my > part. > > From last I played with jboss/testsuite (a while ago), most tests were run > from JUnit by deploying something into a running server, pounding on it and > then undeploying the app. I think this is good for many tests, there are > some tests where we might want to avoid the deploy/rmi->exec/undeploy bits > and simply execute the code directly. This would test the functionality of > that code with out any additional factorys from the deploy/rmi/undeploy. > > In the case of JMS internals I think this is a great place to start. Could > be that is what you are doing already... I would have to look at the > testsuite again to become more familar with it. > > > (1) that we are correctly flushing out our output to disk when we commit a > > transaction. All message are FULLY written to disk by the time the commit > > is issued. > > Probably the only way to ensure this would be to sync the FileDescriptor, > then re-read the log. Assuming that FileDescriptor.sync() will actually > sync correctly or throw an exception, once you pass this method you are > assured that the data written has actually flushed... more or less. Could > be that the fs was really a ramdrive, or a raid-cache with no battery > backup, but there is nothing you can do about that. > > Once you write one, sync. You can re-read the log and expect to have > exactly one log, which will have the expected attributes and such. Anything > else is a problem. > > > (2) that we do not attempt to recover messages from transaction that did not > > commit. > > If the tx did not commit would it have been sync'd to disk? Not really sure > how all that XA fluff works, so I have no clue how to test that. > > > (3) that we can deal with garbage at the end of out transaction logs. > > Re-reading the tx log after a set of pre-descripted events should provide > coverage of most of the problems. > > > Would HARD Killing the server after a commit test (2)??? How would we > > implement the HARD kill (JNI)?? > > I have no clue as to the best way to test a total VM failure. Sure a JNI > could call exit(), but then you would have to have some external process > monitoring the test, and then some way to start up a new vm and communicate > with it. > > Perhaps we need a bit of JUnit framework to do this? This could be used to > do the end-to-end testing, where the testing vm would start up the JBoss vm > (or more than one for distributed tests) and the could kill them as needed. > > Then you could setup any given environemnt, perhaps it was a standalone > JBoss, or perhaps it was a specialed TestCase or TestSuite, which is rather > volitle. > > Does such a JUnit modification/integration suite exist? > > --jason > > > _______________________________________________ > 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
