Какие методы вы используете для отладки сложных привязок guice? - PullRequest
Новая
       4

Какие методы вы используете для отладки сложных привязок guice?

12 голосов
/ 22 декабря 2011

У меня есть сложный набор привязок, который включает в себя множество частных привязок для решения проблемы ноги робота .

Из-за ограниченной способности Guice сообщать о понятных ошибках связывания, мне интересно, какие эффективные инструменты или методы, если таковые имеются, кроме чтения исключений времени выполнения Guice, доступны для устранения ошибок привязки во время выполнения.через конфигурационный код не помогает, потому что конфигурация происходит во время загрузки, а не во время создания объекта, где обычно происходят ошибки.

Плагин Guice graph, вероятно, был бы полезен, если бы он работал - мои эксперименты с ним привели к некорректным графикам.

1 Ответ

7 голосов
/ 11 января 2012

Я нашел следующие два совета полезными для отладки из этого ответа :

  • Grapher визуализирует инжекторы.Если ваш пользовательский провайдер реализует HasDependencies , он может дополнить этот график.
  • Binder.skipSources () позволяет вам писать расширения, сообщения об ошибках которых правильно отслеживают номера строк.

Binder.skipSources () полезно, если вы пишете универсальные вспомогательные методы привязки, а Guice сообщает только номер строки универсального вспомогательного метода, но вы (скорее всего) действительно хотитеномер строки вызывающего абонента на один уровень выше стека.

Я занимаюсь разработкой для Android, поэтому время сборки может быть довольно медленным с момента, когда я изменяю свои привязки, пока не увижу результаты моих изменений наустройство или симулятор.Поэтому я разработал модульные тесты, которые будут проверять привязки Guice непосредственно на главном ПК.Даже если вы не разрабатываете для Android, полезно написать модульные тесты привязки Guice следующим образом.Прямо сейчас мой выглядит примерно так (здесь, в Scala - Java будет выглядеть похоже) 

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])
    }   
}

Я пишу тесты, начиная с самого глубоко связанного класса.Т.е., если C вводится в B, который вводится в A, я начну тестирование в C. Если не удастся выполнить модульное тестирование привязки C, я начну комментировать введенные поля в C, пока не получу привязку для успешного выполнения.Затем я продвигаюсь вверх по иерархии внедрения, повторяя этот процесс.

Конечно, если вы будете следовать разработке, управляемой тестами, и обязательно включите в свой набор тесты привязки Guice с полным покрытием, вы обнаружите этиошибки, как только вы нарушаете привязку.

...