Basically, yes. Ideally you'd retain as many "real" bindings as possible, as to test most of the production aspects of your system. The mock bindings would override some of these real bindings to do things like stub out backends.
On Thu, Aug 18, 2011 at 5:16 PM, Nathandelane <[email protected]>wrote: > Thanks you for taking the time to respond. Let me see if I understand > you basically correctly. It appears as though you are using > Modules.override(...).with(...) to ensure that a mock module is > utilized. Is that correct? > > On Aug 18, 12:43 pm, Fred Faber <[email protected]> wrote: > > Let me try first a quick answer, then we can iterate over details if > you'd > > like. > > > > The use of Modules.override() here is what gives the ability to mock a > set > > of components that effectively represent interfaces to those components > from > > a system. For example, if you have something like: > > > > class MakesRpcCalls { > > @Inject MakesRpcCalls( > > RpcInterface rpcInterface) { > > ... > > } > > > > RpcResponse makeRpc(RpcRequest rpcRequest) { > > ... do some stuff > > return rpcInterface.call(rpcRequest); > > } > > > > } > > > > You might want to mock RpcInterface in your test. > > > > Imagine the module that binds this interface in production looks like: > > > > public class RealRpcInterfaceModule extends AbstractModule { > > @Override protected void configure() { > > bind(RpcInterface.class).to(RealBackendServiceInterface.class); > > ... > > } > > > > } > > > > And your application module might then install it: > > > > public class ApplicationModule extends AbstractModule { > > @Override protected void configure() { > > install(new RealRpcInterfaceModule()); > > .... > > } > > > > } > > > > And your main() method might look like: > > > > public static void main(String[] args) { > > Injector injector = Guice.createInjector(new ApplicationModule()); > > Server server = injector.getInstance(Server.class); > > server.runForever(); > > > > } > > > > In an integration test, you'd want to be able to do something like start > > this server pointing at a mock rpc backend. One way to do this is to add > > another method: > > > > public static void main(String[] args) { > > // imagine 'EmptyModule' is one with no bindings. thus, by default, > > // don't override any bindings within 'ApplicationModule' > > programmaticMain(args, new EmptyModule()); > > > > } > > > > /** > > * Accepts the args from the command line and an {@code overrideModule}, > > the > > * bindings in which are used to override bindings in the {@link > > ApplicationModule}. > > */ > > public static void programmaticMain(String[] args, Module overrideModule) > { > > Module moduleToUse = Modules.override(new > > ApplicationModule)).with(overrideModule); > > Injector injector = Guice.createInjector(moduleTouse); > > Server server = injector.getInstance(Server.class); > > server.runForever(); > > > > } > > > > In your integration test, you'd then start a server with: > > > > Server.programmaticMain(<args>, new AbstractModule() { > > @Override protected void configure() { > > bind(RpcInterface.class).to(MockedOutRpcInterface.class); > > } > > > > } > > > > Of course many variations on this theme exist, but the gist of overriding > > production bindings remains the same. > > > > Fred > > > > On Thu, Aug 18, 2011 at 12:13 PM, Nathandelane <[email protected] > >wrote: > > > > > > > > > > > > > > > > > For a long time I have been working on a series of automated tests > > > that rely on the creation of mocks through a service lookup utility > > > (like Spring framework's), which in some ways resembles a dependency > > > injection framework and is used like a DI framework, but it doesn't > > > quite work the same way, and it has some intricacies that make it less > > > reliable for DI in my opinion. Recently I've been trying to implement > > > the usage of Guice in place of this service lookup utility, and I've > > > been running into a possible issue that I can't seem to figure out. I > > > however suppose that I must be missing something in relation to Guice. > > > > > Essentially there are cases when we mock portions of a system and set > > > them up in advance of running that system. Our service lookup utility > > > in this sense seems to be global. In Guice however there seems to be a > > > requirement of concrete implementations of AbstractModule or more > > > correctly the Module interface. It seems to me that all of the > > > examples provided use those implementations explicitly right before > > > requesting an instance of an interface in question. If this is the > > > case, then how would I implement my integration tests using Guice to > > > mock certain portions of a system in advance of calling that system, > > > and ensure that my mocks (in a Module implementation) get used? There > > > isn't any way to do this is there? Because Guice isn't global, or > > > rather the bindings aren't global to the test application or > > > application under test, rather they are local. > > > > > This is probably a special situation. Can anybody please help me > > > clarify this point? > > > > > Thanks. > > > > > Nathan Lane > > > > > -- > > > 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. > > -- > 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. > > -- 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.
