Мне нужна помощь с тестами JUnit и событиями CDI

Question

Мне нужна помощь в создании теста для моего класса. Этот класс очень полезен, и мне не разрешается проводить его рефакторинг, так как у меня нет времени (по крайней мере, моя компания не выделяет на это время).

Мне нужно использовать поддельный класс, но он выглядит так:

@Inject
    protected ClassZ(ClassA classA, ClassB classB, ClassC classC, 
                     ClassD classD, ClassE classE, ClassF classF, 
                     ClassG classG, ClassH classH, ClassI classI, etc..)

    public void complexMethod()
    {
        // reads from files using classA, does stuff with classB, etc.
    }

Mockito не работает для меня, потому что те классы, которые вводятся, выполняют кучу работы: чтение из файлов, запись в файлы, хранение базы данных в памяти и т. д. c. Я знаю, это плохой код, но я застрял с , нуждающимся в реальных экземплярах моих классов. Аннотация @Spy все еще выполняет методы по умолчанию. Таким образом, boolean readFile возвращает False каждый раз.

Как мне избежать ада зависимости? Мне всегда нужно @Inject ввести все зависимости или использовать @AdditionalClasses для их перечисления. Есть ли лучший способ?

Answer 1

Я не уверен, что понимаю, что вы ищете, но если это тестирование JUnit с включенным CDI, посмотрите на weld-junit . Он работает с JUnit 4 или 5 и запускает Weld перед запуском теста, позволяя вам указать, что должно быть в архиве компонента (или оставить его для обнаружения). Самая новая версия предназначена для CDI 2.0, более старая была и для 1.2. Не уверен, какой из них вы используете.

Это позволяет вам тестировать в полноценной среде CDI, не издеваясь над ней. Это может или не может быть то, что вы после. Вам все равно придется загружать эти классы в CL, но вы можете ограничить обнаружение таким небольшим набором, который требуется тестом.

Answer 2

Тьфу. У меня есть подход. Это НЕ рекомендуется, но мне нужно было запустить интеграционные тесты вчера. Я публикую этот ответ на тот случай, если кто-то другой страдает так же, как и я.

Я нашел подходящее решение для моих тестов JUnit благодаря коллеге, который через него говорит. Оказывается, на 100% допустимо использовать Weld в вашем @Before методе. Я загружаю все с помощью Weld и создаю их экземпляры с помощью вызова CDI.current().select().get() следующим образом:

@Before
public void setup()
{
    RuntimeSupport.initializeDefaults();
    Weld weld = new Weld();
    weld.initialize();
    classZ = CDI.current().select(ClassZ.class).get();
}

Иногда это требует ручного создания других зависимостей:

например.

ClassY classY = CDI.current().select(ClassY.class).get();
classY.toString(); // ugly forced construction

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