> It would be nice to have a stable qa suite branch for testing River > development and another for refactoring and developing the test suite > itself, without interfering with the development process of River. The > test suite requires maintenance too, but right now it's a frightening > prospect. > > I think it's essential to sort this out. I reckon we ultimately should be aiming at having an up-to-date/parallel developed test suite for trunk and indeed skunk. Bad test/compile process otherwise.
But there's a catch... > I'd like to be able to run an experimental test suite with a stable River > trunk to test the test suite so to speak. > > I think that's wise equally I'm pondering how you cope with trunk moving on and breaking a bunch of your tests for which there would be fixes in the trunk test suite. Are you happy doing merges as and when or ??? > When River was set up from the donated Jini code, the qa suite was an > independantly developed library accompanied by integration tests, it was > integrated because it was converted to ant from an old make build few know > how to compile or run. > > The tests can be brokend down into: > > 1. Jini specification tests. > 2. Implementation integration tests. > 3. jtreg regression and unit tests. > > Some other benefits might be: > > The tests don't change much so using them as a library reduces compile and > build time, encouraging testing more often. > > Since the last release I've found numerous concurrency and synchronization > issues with the test suite, this is made more difficult by the inheritance > hierarchy of the test suite. I'd like to do more refactoring of the test > suite, but do so against a stable trunk, without hindering trunk > develpment, since it could take some time. > > Regards, > > Peter. > >
