I actually test some modules indirectly by creating the injector in the tests... this is for some unit tests where I could not fully decouple the classes.
So, bottom line is: there's no point in *unit* testing modules, right? Thanks for your reply On Sep 9, 2:17 pm, Sam Berlin <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
