> I'm not yet ready to buy modules as being a decent divide point for tests. > Tests are typically associated with packages, not modules IMHO. > > Feels like an impedance mismatch or maybe I'm not liking how much the > build/deploy/package mechanism is a factor in a discussion about testing.
Currently we have: Unit tests: junit Integration tests: qa test harness. Jini platform compliance tests: qa test harness Regression tests: jtreg On top of that we've got the discovery and join test kit. We're very lucky to have such a vast array of tests. It would be nice if I could just work on a small part of what is River, improve it using test driven development by only running the tests needed. It seems that you must first build before you can test, sometimes it is wise to find the right questions before looking for the answer. We don't build junit or jtreg every time we test, why can't the qa harness be separate too? Why can't a component such as Outrigger be kept separate from the jini platform build? Why can't it have the tests that must be run to test it be known in advance, or compiled in advance for that matter? Why isn't it easy to determine the tests that need to be run to test a component? Is there a better solution? If not I'll have to face facts: my development windows of opportunity don't allow enough time to adequately test changes. Maybe modularity is not the answer, maybe I'm grasping at straws. I don't know, these things take time to figure out. Can anyone else see the problems? Anyone here know the right questions? With the right questions, answers are easier to find.
