Guice: What is the appropriate way to write test in guice project?

Created on 5 Jul 2017  路  5Comments  路  Source: google/guice

I feel apologetic to ask for help in github issue. I am new in google guice and got stuck in writing test for a guice project.

So for example I have a singleton bean:

~ java
@Singleton
class A {
public String hello() {
return "helloworld";
}
}
~

What is the appropriate way to write unit test for A class? My experience is that I should get the bean without loading the whole context and test its behavior separately.
This is how I can test it in a Spring and Mockito way:

~~~ java
public class ATest {
@InjectMocks
private A a;

@Test
public void testAIsPresent() {
    assertNotNull(a);
}

}
~~~

I believe there should be a similar way in Guice to write test like this. But I search anywhere and could not find any workable approach. Am I doing it in a wrong way in Guice? Is there any docs for writing test in guice?
Thanks so much.

Most helpful comment

The only mention in the docs AFAIK is the recommendation to use a package private constructor, to balance the best practice of keeping constructors as hidden as possible against testability.
https://github.com/google/guice/wiki/KeepConstructorsHidden

Example:

public class FooBar {
  private FooService fooService;
  private BarManager barManager;

  @Inject FooBar(FooService fooService, BarManager barManager) {
    this.fooService = fooService;
    this.barManager = barManager;
  }

  int compute() {
    return fooService.getSomething() + barManager.getSomethingElse();
  }
}

public class Test {
  @Mock FooService fooService;
  @Mock BarManager barManager;

  @Test public void testCompute() {
    // stubbing method calls
    when(fooService.getSomething()).thenReturn(41);
    when(barManager.getSomethingElse()).thenReturn(1);

    // direct instantiation 
    FooBar fooBar = new FooBar(fooService, barManager);

    assertEquals(42, fooBar.compute());
  }
}

All 5 comments

For unit tests you shouldn't need to use Guice at all; just construct your subject under test as normal, passing in mocks/fakes/etc. as needed.

For integration tests just create an Injector that depends on the modules you're trying to test, and replace "production" modules with "testing" modules as necessary. BoundFieldModule is nice for binding mocks.

Hi, @dimo414 . Thanks for your response. May I ask for some example codes?

The only mention in the docs AFAIK is the recommendation to use a package private constructor, to balance the best practice of keeping constructors as hidden as possible against testability.
https://github.com/google/guice/wiki/KeepConstructorsHidden

Example:

public class FooBar {
  private FooService fooService;
  private BarManager barManager;

  @Inject FooBar(FooService fooService, BarManager barManager) {
    this.fooService = fooService;
    this.barManager = barManager;
  }

  int compute() {
    return fooService.getSomething() + barManager.getSomethingElse();
  }
}

public class Test {
  @Mock FooService fooService;
  @Mock BarManager barManager;

  @Test public void testCompute() {
    // stubbing method calls
    when(fooService.getSomething()).thenReturn(41);
    when(barManager.getSomethingElse()).thenReturn(1);

    // direct instantiation 
    FooBar fooBar = new FooBar(fooService, barManager);

    assertEquals(42, fooBar.compute());
  }
}

Guice documentation recommends not have to have public constructor for Classes that use guice injection.

https://github.com/google/guice/wiki/KeepConstructorsHidden

In this case, the what would be the best technique to write unit tests?

@HyperDunk then you should have package-private constructors. Check the example of @cardamon a few posts earlier.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jhm-ciberman picture jhm-ciberman  路  10Comments

scottcarey picture scottcarey  路  17Comments

avoss picture avoss  路  17Comments

ronshapiro picture ronshapiro  路  12Comments

prasanthgithub picture prasanthgithub  路  14Comments