I've been thinking about our previous discussion - under the topic "NPE in MclStorageManager".
I feel the set up for some of our unit tests is so complex that it is very difficult to walk cold into a problem and start writing new test cases to expose a bug. If it isn't easy to write tests, then most people won't write them.
Of course, many logic paths cannot be tested without a significant envelope of support software, usually including felix. However, many classes have methods whose corner cases could be tested and debugged under a much simpler environment. I've been thinking and developing a change that would enable this additional mode of development.
I have extended the concept behind your testing.properties property called TEST_LIST. I've defined a new property called SLICKLESS_TEST_LIST that defines all the slickless test classes.
SlicklessTests runs under felix and executes the existing slickless test classes using their hard-coded names. I have modified SlicklessTests to use the new property instead. This means it is very easy for someone to incorporate a new test class that can be run or debugged outside felix. This has the added advantage that when you run a full set of tests, the SlicklessTests runner picks up ALL these slickless tests and so they automatically appear in the xml/html test results reports.
I have also modified the SlicklessTests class so that it can run those tests outside felix - provided they don't actually require felix. This logic is a bit primitive, but I'm trying not to run too fast until I can walk.
I've modified the existing test target in the build to pick up the new properties list and so allow SlicklessTests to discover its subordinate test classes.
I've also added a new build target (a bit primitive at the moment) to run the SlicklessTests under jUnit (i.e. without felix). It either runs the default set from testing.properties, or allows you to over-ride via -Dtest.name.
I'd like to commit these changes before I develop any further. I want to add a netbeans target to debug a specific slickless test. Also, my current logic requires a fully-qualified package name for the test class and I wonder whether I can use simple classnames (without having to re-invent felix, of course!)
Once I've got this infrastructure working, I want to get back to the original problem!! I want to write some new low-level (non-felix) unit tests that expose the NPE in the MclStorageManager call stack.
What do you think?