On 11/11/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
AIUI, your proposal means multiple jars (instead of just james.jar), multiple separate components,
Yes.
and complicates refactoring/introduction of new internal modules. No?
No, it doesnlt have to. I understand why you wouldn't want to take my word for it, but next time I see you I'll show you how it can be done. We did exactly this at work, moved from 1big jar in an ear to dozens of tiny ones in an ear, it really helps agility and testing.
> James is a collection of such things, mostly we don't need to build > the whole thing over and over. And generally we don't, although I just changed that for a dist build, which should be built from scratch. The topic is running tests.
Yeah, we should only run tests on things which have changed. So the scope of change is on topic.
Selective testing would need to know the internal dependency graph in order to know if a change in a seemingly unrelated file requires running a test on a given component.
Yeah unless you are strict and unit test compliance with interfaces and only test functionally and for integration later.
Compile time and assembly level dependencies would need to be kept in synch with the test configuration, and that doesn't include tracking "hidden" dependencies, such as global services exposed via a locator. It can be done, but I'd consider it safer to just run all of the tests, except when a developer makes a conscious decision to run just one that he or she needs.
Those things are functional and integration tests, we were talking about unit testing. I'm happy to talk about automated functional and integration testing, but that is a very different kettle of fish.. d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
