If the only problem you are trying to solve is testing of singletons, then Guice doesn't offer you much advantage.
Remember that Guice is primarily designed to make implementation of dependency injection simpler, and that's a design pattern which will affect your entire code base, if your code is not factored that way. Scoping (e.g. singletons) is another feature provided by Guice to help simplify the DI pattern, but it is only one aspect. DI isn't just about testability, but other factors such as code reuse as well. A singleton which is implemented as a static will be less reusable than an object bound in SINGLETON scope with Guice, since you can decide whether it should be a singleton, bound in request or session scope (for a web app), thread scope etc. A singleton in one app, might be suitable in a different scope usage in a different app. On Oct 26, 6:14 am, Gili <[email protected]> wrote: > Hi, > > It is my understanding that one of the main reasons for using Guice is > that it is difficult to ensure that static state (such as singletons) > get reset across JUnit tests. Isn't that what ClassLoaders are for? > > What's the advantage of using Guice versus a JUnit runner that simply > uses a different ClassLoader per test to ensure that static state gets > reset? > > Thanks, > Gili --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
