Question

I have a complex set of bindings that include many private bindings to solve the robot legs problem.

Because of Guice’s limited ability to report intelligible biding errors, I’m wondering what effective tools or techniques, if any, besides reading Guice’s runtime exceptions are available to troubleshoot runtime binding errors.

Stepping through configuration code isn’t helpful, because the configuration happens at boot time rather than at object instantiation time, where errors usually occur.

The Guice graph plugin would likely be useful if it worked–my experiments with it have resulted in incorrect graphs.

Answer 1

I found the following two tips useful for debugging from this answer:

• Grapher visualizes injectors. If your custom provider implements HasDependencies, it can augment this graph.
• Binder.skipSources() lets you to write extensions whose error messages track line numbers properly.

Binder.skipSources() is useful if you write generic binding helper methods and Guice only reports the line number of the generic helper method, but you (most likely) actually want the line number of the caller one level up the stack instead.

I’m developing for Android, so the build time can be quite slow from the time I modify my bindings until I see the results of my changes on the device or simulator. So I’ve developed unit tests that will verify the Guice bindings directly on the host PC. Even if you’re not developing for Android, it can be helpful to write Guice binding unit tests as follows. Right now, mine look something like this (here in Scala–Java would look similar)

class ProviderTest {
    var injector : Injector = null

    @Before
    def setUp() {
        injector = Guice.createInjector(
            new BindModule1(),
            new BindModule2(),
            new BindGlobals()
            )
    }

    @After
    def tearDown()  {
    }

    @Test   def InjectedClass1WasBound()  {
        val provider = injector.getProvider(classOf[InjectedClass1])
    }

    @Test   def InjectedClass2WasBound() {
        val provider = injector.getProvider(classOf[InjectedClass2])
    }   
}

I write tests starting from the most deeply-bound class. I.e., if C is injected into B, which is injected into A, I’ll start testing at C. If unit testing C’s binding fails, I’ll start commenting out the injected fields in C until I get the binding to succeed. Then I move my way up the injection hierarchy repeating this process.

Of course if you follow test-driven development, and make sure to include full-coverage Guice-binding tests in your suite, you’ll detect these errors as soon as you break a binding.