For the particular case of testing the contributions you could of course also use the Registry's getConfiguration() method and set the returned List manually in the test.
But I see where you're getting at. This is an area where I think it could be interesting if the Registry exposed an additional method to "autowire" an object. E.g. registry.injectServices(mockService); But also a facility for overriding services as you describe it sounds interesting. --knut On Sun, 31 Oct 2004 18:11:58 +0700, Jean-Francois Poilpret <[EMAIL PROTECTED]> wrote: > Hello Knut, > > Yes of course I did that for my _true_ unit tests. > > But I wanted to go further with partial _integration_ tests within HiveMind > (in particular I wanted to check that my contribution rules worked OK and I > got the List of the right objects, for that, obviously, I need to integrate > with HiveMind). However, I would like to avoid _full_ integration tests for > the moment (I mean, let Hibernate aside in my partial integration tests). > > So the reason of my question. > > Cheers > > > > > -----Original Message----- > From: Knut Wannheden [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 31, 2004 4:07 PM > To: [email protected] > Subject: Re: Overriding services > > Jean-Francois, > > I'm not sure I quite understand your problem. But can't you just > write your test for service B without using HiveMind? E.g. > > A mockA = new AMockImp(); > B b = new BImpl(); > b.setA(mockA); > > Also note the services hivemind.lib.DefaultImplementationFactory and > hivemind.lib.PlaceholderFactory. > > --knut > > On Sun, 31 Oct 2004 13:45:24 +0700, Jean-Francois Poilpret > <[EMAIL PROTECTED]> wrote: > > Hi, > > > > Yesterday I was stuck with the following problem: > > - I have a service-point A that is used internally by some other > > service-point B > > - service-point A implementation depends on some "heavy" processing (it > uses > > Hibernate to create a SessionFactory based on a configuration file and > some > > additional properties) > > > > I had the need to do some "partial integration test" of service B inside > > HiveMind, but I did not want to use real Hibernate stuff (this would make > > the test too long and uselessly complicated). > > > > Originally, in the module where services A and B are defined, I put the > > implementation declaration for A directly in service-point declaration. > > But then I could not override A implementation for testing purposes (for > > testing I needed to mock service A implementation). > > > > So I started to check how I could "override" service A implementation for > my > > tests. > > > > On Hibernate web site, there is a page on overriding services, this way is > > probably a good way to follow for a service-point that is _intended_ to be > > overridden by the application, but I found it a bit heavy just for testing > > purposes. > > > > Finally, I could not come out with a _good_ solution to my problem and I > > gave up to what I considered the best solution I had on-hand for the job > > (best but not really good actually): > > - in module descriptor for services A & B, I removed the "invoke-factory" > > from service-point A, just keeping the service-point declaration. > > - in my tests, I had a descriptor that includes the implementation for > > service A (in this case the implementation points to a class that is > > directly defined in my test case, and that delegates all method calls to a > > Mock object) > > - unfortunately (this is where the solution is not really good), in the > > final application descriptor module, I (and other application developers > > too) _have_ to include the implementation for service A, although it is > > supposed to be always the same. > > > > I think that, probably (as suggested in the web page regarding override of > > services), it would be interesting to have a HiveMind-defined way to do > > that, ie: > > - defining a default implementation for a service-point > > - having the built-in possibility to override it in another module > > In the situation of my test case, it would have the advantage of being > > unobtrusive to the end-application developer. > > > > Should this be an enhancement request? > > Or have other developers in the list faced the same problem and could come > > out with a different solution? > > > > Cheers > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
