You can indirectly test modules by using integration tests where you create an Injector using your modules and ensure that pieces of the program work. As far as testing any logic in the modules... there ideally would be no logic in the modules, just bindings. Logic should be separated into different modules that are installed in different circumstances.
Sam On Wed, Sep 9, 2009 at 5:08 PM, Pablo Fernandez <[email protected]>wrote: > > Hi, > > I'm running my tests with a code coverage tool and for the only > classes I get 0% coverage are my Guice Modules. No big deal, but just > lead me to think... > > Is there any benefit in testing Guice Modules? I've tried to test one > and that implied: > > 1) using Module interface instead of AbstractModule class (code > readability decreased a bit) > 2) mocking the hell out of the binder (so much that I don't really > know if I'm actually testing something) > > In fact after doing this, the test and the module look pretty much the > same... > > isn't this just fancy code duplication? has anyone tested their own > modules? is there any outcome in doing that (aside reaching 100% code > coverage)? > > Thanks > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
