Can you separate your hibnerate stuff into another jar file and then supply a mock jar for integration testing?
Albert --- Jean-Francois Poilpret <[EMAIL PROTECTED]> 內容： > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
