You possibly could get around it like that - I would think though that it would be a rather flaky solution and would advise against something that complex though.
Guice should have nothing to do with your classloader(s) during testing, Guice only does DI and it is the DI pattern that makes your tests simpler. After all, the point is to have tests that are completely isolated from each other and do not share state. On Sun, Oct 25, 2009 at 9:14 PM, 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 -~----------~----~----~----~------~----~------~--~---
