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
