Testing¶
Test support require io.dropwizard:dropwizard-testing:1.0.6
dependency.
Junit¶
Testing core logic¶
For integration testing of guice specific logic you can use GuiceyAppRule
. It works almost like
DropwizardAppRule,
but doesn't start jetty (and so jersey and guice web modules will not be initialized).
Managed and lifecycle objects supported.
public class MyTest { @Rule GuiceyAppRule<MyConfiguration> RULE = new GuiceyAppRule<>(MyApplication.class, "path/to/configuration.yaml") public void testSomething() { RULE.getBean(MyService.class).doSomething(); ... } }
As with dropwizard rule, configuration is optional
new GuiceyAppRule<>(MyApplication.class, null)
Testing web logic¶
For web component tests (servlets, filters, resources) use DropwizardAppRule.
To access guice beans use injector lookup:
InjectorLookup.getInjector(RULE.getApplication()).getBean(MyService.class);
Spock¶
If you use spock framework you can use spock specific extensions:
@UseGuiceyApp
- internally useGuiceyAppRule
@UseDropwizardApp
- internally useDropwizardAppRule
Both extensions allows using injections directly in specifications (like spock-guice).
@UseGuiceyApp¶
@UseGuiceyApp
runs all guice logic without starting jetty (so resources, servlets and filters are not available).
Managed objects are handled correctly.
@UseGuiceyApp(MyApplication) class AutoScanModeTest extends Specification { @Inject MyService service def "My service test" { when: 'calling service' def res = service.getSmth() then: 'correct result returned' res == 'hello' }
Annotation allows you to configure the same things as rules does: application class, configuration file (optional), configuration overrides.
@UseGuiceyApp(value = MyApplication, config = 'path/to/my/config.yml', configOverride = [ @ConfigOverride(key = "foo", value = "2"), @ConfigOverride(key = "bar", value = "12") ]) class ConfigOverrideTest extends Specification {
As with rules, configOverride
may be used without setting config file (simply to fill some configurations)
@UseDropwizardApp¶
@UseDropwizardApp
is useful for complete integration testing (when web part is required):
@UseDropwizardApp(MyApplication) class WebModuleTest extends Specification { @Inject MyService service def "Check web bindings"() { when: "calling filter" def res = new URL("http://localhost:8080/dummyFilter").getText() then: "filter active" res == 'Sample filter and service called' service.isCalled()
Annotation supports the same configuration options as @UseGuiceyApp
(see above)
Spock extensions details¶
Extensions follow spock-guice style - application started once for all tests in class. It's the same as using rule with
@ClassRule
annotation. Rules may be used with spock too (the same way as in junit), but don't mix them with
annotation extensions.
There are two limitations comparing to rules:
- Application can't be created for each test separately (like with
@Rule
annotation). This is because of@Shared
instances support. - You can't customize application creation: application class must have no-args constructor (with rules you can extend rule class
and override
newApplication
method). But this should be rare requirement.
All guicey tests use spock, so you can see extensions usage examples there.
To better understand injection scopes look the following test:
@UseGuiceyApp(AutoScanApplication) class InjectionTest extends Specification { // instance remain the same between tests @Shared @Inject TestBean sharedBean // new instance injected on each test @Inject TestBean bean // the same context used for all tests (in class), so the same bean instance inserted before each test @Inject TestSingletonBean singletonBean def "Check injection types"() { when: "changing state of injected beans" sharedBean.value = 10 bean.value = 5 singletonBean.value = 15 then: "instances are different" sharedBean.value == 10 bean.value == 5 singletonBean.value == 15 } def "Check shared state"() { expect: "shared bean instance is the same, whereas other one re-injected" sharedBean.value == 10 bean.value == 0 singletonBean.value == 15 // the same instance was set before second test } // bean is in prototype scope static class TestBean { int value } @Singleton static class TestSingletonBean { int value } }
Overriding beans¶
There is no direct support for bean overrides yet (it is planned), but you can use the following approach.
First, prepare custom injector factory:
public class CustomInjectorFactory implements InjectorFactory { private static ThreadLocal<Modules[]> modules = new ThreadLocal<>(); @Override public Injector createInjector(Stage stage, Iterable<Module> modules) { Modules[] customModules = modules.get(); modules.remove(); return Guice.createInjector(stage, customModules == null ? modules : Lists.newArrayList(Modules.override(modules).with(customModules)) ) } public static void override(Module... modules) { customModules.set(modules); } public static void clear() { customModules.remove(); } }
It allows using guice Module.overrides()
for bindings substitution.
Register factory in guice bundle:
GuiceBundle.builder() .injectorFactory(new CustomInjectorFactory())
Guice Module.overrides forcefully override (substitute) all bindings from override modules. So all modules in your application remain the same but you can create new test modules with test specific replacements.
For example, suppose we have some service CustomerService
and it's implementation, defined in appllication
CustomerServiceImpl
. To override it we prepare new test module:
public class TestModule extends AbstractModule { @Override protected void configure() { bind(CustomerService.class).to(TestCustomerServiceImpl.class); } }
Now register overriding module:
CustomInjectorFactory.override(new TestModule());
Warning
Overriding modules registration must be performed before guicey start.
After startup, application will use overridden customer service version.
Of course this approach is far from ideal, but it's the best option for now.
Note
Thread local is used to hold overriding modules to allow concurrent tests run.
This mean you have to manually clean state after each test to avoid side effects:
CustomInjectorFactory.clear()
(of course, if overriding is not used for all tests)