@Stuart: I may have seen the project pages for guiceberry and mycila (not
atunit) when their creators posted to this forum. I thought that I had
missed something that Guice was already capable of handling that I did not
know about.

In my Spring xml configuration, the service instance would be agnostic about
the injected dao.

<!-- Production Mapping Using JNDI Based DataSource -->
<bean id = "myDao" class = "myproject.MyDao">
   <constructor-arg>
     <bean class = "org.springframework.jndi.JndiObjectFactoryBean">
         <property name = "jndiName" value = "myDataSource" />
     </bean>
    </constructor-arg>
</bean>

<!-- Test Configuration -->
<bean id = "myDao" class = "myproject.MyDao">
   <constructor-arg>
      <bean id =
"org.springframework.jdbc.datasource.SimpleDriverDataSource">
        <property name = "driverClass" value = "org.postgresql.Driver" />
        <property name = "url" value = "jdbc:postgresql://localhost:5432" />
        <property name = "username" value = "postgres" />
        <property name = "password" value = "password" />
      </bean>
   </constructor-arg>
</bean>

<!-- Service Configuration neither changes in production nor in test. -->
<bean id = "service" class = "myproject.Service" >
   <constructor-arg ref = "myDao" />
</bean>



On Sun, Jun 28, 2009 at 2:04 AM, Stuart McCulloch <[email protected]> wrote:

> 2009/6/28 Karthik Krishnan <[email protected]>
>
>>
>> @Stuart: Spring Unit Testing Framework allows you to configure a xml
>> file path for it to pick up test configurations. If you were to
>> replace JNDI data source with a DM based on in your test
>> configuration, Spring can it pick it up without any trouble. You don't
>> have to make any changes to your code.
>>
>> http://static.springframework.org/spring/docs/2.5.x/reference/testing.html#junit38-legacy-support
>>
>> http://static.springframework.org/spring/docs/2.5.x/reference/testing.html#testcontext-fixture-di
>>
>
> right - this is a test utility that Spring provides to help with testing
> and there's no technical reason why something similar couldn't be
> done with Guice, by scanning for the modules to be used when
> building the testcase
>
> I'm not sure if you've seen these links before:
>
>   http://code.google.com/p/guiceberry/
>   http://code.google.com/p/atunit/
>
>   http://www.developer.com/design/article.php/3684656
>   http://www.developer.com/java/ent/article.php/3688436
>
>   http://java.dzone.com/announcements/unit-testing-with-spring-guice
>
> but there are a number of third-party extensions that provide test
> integration that might be comparable (unfortunately I haven't used
> the Spring test support myself so I can't do a proper comparison)
>
> Consider my example that I provided in my original post. With Guice,
>> to create an instance of Service (I may be wrong), I have to execute
>> the following lines of code in the class that needs to invoke the
>> service to inject my dependencies.
>>
>> Injector injector = Guice.createInjector(new JndiDataSourceModule());
>> Service service = new Service(injector.getInjector(MyDao.class));
>>
>> This binds my code to JndiDataSourceModule and I can not override this
>> module with DriverManagerDataSourceModule within my unit tests. Is
>> this a correct assumption?
>>
>
> how would you construct your service with Spring? if you do something
> similar with Guice as you would with Spring then it should have the same
> opportunity to inject the code being tested
>
> for example, say you call Spring to create your service instance and
> it looks for the XML to use to configure it - that's effectively the same
> as calling Guice and it using classpath scanning (or something similar)
> to find the modules that should be used to configure your service
>

Not exactly: When you run a unit test (JUnit for eg from your IDE say), the
setUp() calls a method
you are supposed to override in your junit test

public String[] getConfigLocations() (JUnit 3.8.x) or annotating the test
class with @ContextConfiguration(locations={"daos.xml"}) (JUnit 4.x).

This lets the Spring know of your test configurations .

>
>
> that would avoid the reference to JndiDataSourceModule - in the same
> way that you don't hard-code the XML filename, but you let Spring find
> it by scanning the filesystem
>

See above

>
>
> Guice doesn't do classpath scanning itself (it's agnostic about where
> modules come from) but the test frameworks should help you do this
> and will setup the injector for you
>
> ( depending how you arrange your modules you may also need to use
>   Modules.override() as others have already mentioned on this thread )
>
> For unit tests, I can create mock objects and can stub my outputs. I
>> am using Mockito for that purpose. For integration tests, I have to
>> test the work flow. So I have to be able to replace
>> JndiDataSourceModule with DriverManagerDataSourceModule for testing
>> purposes. In my example, I would like to replace one data source with
>> other as seamlessly as possible. I am not an expert on Guice and I
>> would be grateful if you would have any advice or tips for me.
>>
>
> there's a lot of advice contained in the above links, hopefully one of them
> will fit with your current work flow - if not then I'm sure others will be
> able
> to offer further advice on this thread
>
>
>> As for OSGI, I don't want to introduce OSGI yet. My knowledge of OSGI
>> is extremely limited at best so I don't want to introduce anything I
>> don't know yet.
>>
>
> no problem - that's understandable, feel free to bookmark them for later ;)
>
> Thank you for your time and replying.
>>
>> On Jun 28, 12:30 am, Stuart McCulloch <[email protected]> wrote:
>> > 2009/6/27 Karthik Krishnan <[email protected]>
>> >
>> >
>> >
>> > > Adrian: Thanks for your reply: For unit tests, I am mocking behavior
>> > > for the dao class. Ideally I would like to use DM based datasources
>> > > for my integration tests and JNDI based data sources for my
>> > > application to unit test the entire work flow.
>> >
>> > > In Spring it is so easy to do this. I just swap one xml with another
>> >
>> > presumably there's some place in your build or deployment where you make
>> > this swap?
>>
>> Right, I am using Guice in data tier to inject data sources to my
>> daos.
>> >
>> > if so then you could swap the relevant Guice modules at the same point -
>> > either in the
>> > build, or at deployment time by indirectly looking up the modules at
>> runtime
>> > or perhaps
>> > by simply replacing the class on the classpath (say by pre-pending the
>> test
>> > version on
>> > the test classpath)
>> >
>> > afaik there's no reason why swapping classfiles should be harder than
>> > swapping XML
>> >
>> > and let Spring framework handling the switch seamlessly. Idon't know
>> >
>> >
>> >
>> > > how to get Guice to do it for me without having to change the module
>> > > instance.
>> >
>> > > On Jun 26, 11:51 pm, Adrian Cole <[email protected]> wrote:
>> > > > Hi, Krishnan,
>> >
>> > > > I'd extract MyDao's interface and move the other code to
>> DataSourceMyDao.
>> > > > For unit tests, you can mock the behaviour in MyDao specific to that
>> > > test.
>> > > > pita perhaps, but fairly normal.  Creating a more versatile
>> StubMyDao
>> > > would
>> > > > involve some work.  In jclouds, this proved useful, as it helps you
>> load
>> > > > test your code, as opposed to your db.
>> >
>> > > > All this said, you could always fire up an in-process db like derby
>> or
>> > > > hsqldb.  Less work, but it isn't really unit testing at that point
>> ;)
>> >
>> > > > my 2p.
>> > > > -Adrian
>> > > > jclouds <http://code.google.com/p/jclouds>
>> >
>> > > > On Sat, Jun 27, 2009 at 7:57 AM, Karthik Krishnan
>> > > > <[email protected]>wrote:
>> >
>> > > > > Hi Guice Gurus,
>> >
>> > > > > I am just playing with Guice 2.x and I am stuck with an issue that
>> I
>> > > > > can not resolve. Any help would be appreciated.
>> >
>> > > > > I have a service class that takes DAO class as a constructor
>> argument
>> > > > > that connects to the data base. The dao class accepts a data
>> source as
>> > > > > a constructor argument. I have created two modules : the first one
>> > > > > injects a JNDI based data source, the other DriverManager based
>> data
>> > > > > source. I would like
>> >
>> > > > > public class MyService {
>> >
>> > > > >  private final MyDao myDao;
>> >
>> > > > >  public MyService(MyDao myDao) {
>> > > > >     this.myDao = myDao;
>> > > > >  }
>> >
>> > > > >  ....
>> >
>> > > > > }
>> >
>> > > > > public class MyDao {
>> > > > >   private final DataSource dataSource;
>> >
>> > > > >   @Inject
>> > > > >   public MyDao(DataSource dataSource) {
>> > > > >      this.dataSource = dataSource;
>> > > > >   }
>> >
>> > > > >  ....
>> > > > > }
>> >
>> > > > >  My modules:
>> >
>> > > > > public class JndiDataSourceModule extends AbstractModule {
>> >
>> > > > >   public void configure() {
>> > > > >      bind(DataSource.class).toProvider(JndiIntegration.fromJndi
>> > > > > (DataSource.class, "myDatasource"));
>> > > > >   }
>> > > > > }
>> >
>> > > > > public class DriverManagerDataSourceModule extends AbstractModule
>> {
>> > > > >   @Provides
>> > > > >    DataSource getDataSource() {
>> > > > >       return DriverManagerDataSource(driverClass, url, username,
>> > > > > password);
>> > > > >    }
>> >
>> > > > >   ....
>> > > > > }
>> >
>> > > > > I can not figure out how to inject DriverManager based DataSource
>> for
>> > > > > unit tests and JNDI based datasource in my application. I was
>> thinking
>> > > > > of passing modules in the constructor of my service class but I
>> don't
>> > > > > think I would be able to mock my MyDao for exceptional conditions.
>> > > > > Any help would be appreciated.
>> >
>> > --
>> > Cheers, Stuart
>>
>>
>
>
> --
> Cheers, Stuart
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"google-guice" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/google-guice?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to