We have a scenario that is somewhat close to that. In our case, package B simply delegates to a third package that can be determined at run time. This allows us to specify different backend support (in our case different app servers).
-- Rick > -----Original Message----- > From: Michael Kirby [mailto:[EMAIL PROTECTED]] > Sent: Friday, January 11, 2002 2:45 PM > To: [EMAIL PROTECTED] > Subject: [Eap-list] JUnit question (slightly off-topic) > > > This is somewhat related to intellij. > > We have a fairly large project on which we have started to > deploy junit. Writing > drivers is no problem. But stubs, seem more problematic. I > have a scenario where > I want to write junit tests for package A. Package A depends > on package B, which > is a database abstraction layer. Rather than try to pre-load > the database with fake > data that would drive my tests, it would be substantially > easier if I simply provide > alternative implmeentations of package B and include it in my > classpath before the > "real" package B. > > The problem is that I want to be able to test a variety of > scenarios including ones > where I substitute in an alternate implementation of package > B, and some where I > actually use the real one. > > What I can't figure out how to do, is vary the classpath > depending on the test suite. > (i.e. the suite that tests A alone, would use a different > classpath than the suite that > tests the combined A & B). > > Does anyone else do this? And of course, the final question > would be how would I > integrate that into intellij? > > Thanks, > MIke > --- > [EMAIL PROTECTED] > To obtain my PGP public key, mail "SEND PUB KEY" in the > subject to "[EMAIL PROTECTED]" > > > _______________________________________________ > Eap-list mailing list > [EMAIL PROTECTED] > http://www.intellij.com/mailman/listinfo/eap-list > _______________________________________________ Eap-list mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-list
