3

Hoi!Найти все классы, связанные с одним вызовом метода/Arquillian Micro Deployments: как автоматически собирать необходимые классы?

Проблема, которую я обнаружил, довольно прост для понимания, но я не могу найти решение.

Сначала позвольте мне представить этот небольшой фрагмент.

@Deployment 
public static Archive<?> createDeployableArchive() { 
    JavaArchive jar = ShrinkWrap.create(JavaArchive.class, "whoCares.jar"); 
    // enable CDI 
    jar.addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"); 

    // Some persistence 
    jar.addAsManifestResource("test-persistence.xml", "persistence.xml"); 

    // Now the interisting part (simplified): 

    jar.addClass(RegistrationService.class) // This one should be tested 
     .addClass(RegistrationException.class) // Will be thrown on error. 
     .addClass(UserDAO.class) // Used by RegService 
     .addClass(User.class) // JPA Entity 
     // ... 
     // ... This scenario goes without interfaces, inheritance, DTOs, different 
     // ... types of exceptions for different problem types... That's why the list 
     // ... is so concise. 
     // ... 
     .addClass(RegServiceIntegrationTest.class); // Test class must be included 

    return jar; 
} 

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

Выполнение этого вручную будет стоить времени и производить проблемы и ошибки, конечно! Существует несколько слабых мест:

Подумайте о длительном процессе с множеством вспомогательных служб, исключениях, интерфейсах, суперклассах, утилитах и ​​т. Д. Вы пройдете полный поток, чтобы найти все. Честно говоря, это повторяющаяся долговременная работа, которая будет болью ... eyes. Мне пришлось сделать это всего несколько раз, прежде чем я решил скорее начать кричать.

Сохранение ваших тестов в актуальном состоянии: Представьте, что вы подключаете новую вспомогательную услугу к своей цепочке регистрации. Вам придется обновлять эти проклятые зависимости, и если что-то пойдет не так, когда вы запустите свои интеграционные тесты, в конце дня будет весело копаться через иногда неполные сообщения об исключениях (неполная причина, по которой вы знаете только, что в какой-то момент чего-то не хватает, но не то, что в точку). Если вам повезет, возникает ClassNotFoundException. Одно изменение может, конечно, легко повлиять на несколько тестов: 1. Пусть UserDao выкинет какое-то новое причудливое исключение во время выполнения. 2. Отбросьте свое время жизни.

Проблемы с добавлением пакетов: Добавление пакетов предоставляется Shrinkwrap, но использование его было бы плохой идеей. Иногда, после долгого дня, вы чувствуете себя ленивым и просто добавляете полные пакеты, но можете ли вы быть абсолютно уверены, что каждый класс останется в одном пакете навсегда? Другая проблема заключается в том, что термин «микроразведение» подразумевает необходимость в компактности. Целые пакеты вводят накладные расходы, хорошо, я думаю, это самая маленькая проблема.

Как это решить (просто безоговорочные мысли)?

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

Лучшим решением было бы что-то вроде этого:

@Deployment 
public static Archive<?> createDeployableArchive() { 
    JavaArchive jar = ShrinkWrap.create(JavaArchive.class, "whoCares.jar"); 

    // enable CDI 
    jar.addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"); 

    // Some persistence 
    jar.addAsManifestResource("test-persistence.xml", "persistence.xml"); 


    Class<?>[] involved; 
    involved = Tool.findInvolvedClasses("RegistrationService.java", "registerUser"); 
    jar.addClasses(involved); 

    return jar; 
} 

Я не думаю, что можно добиться этого с помощью отражения, как это необходимо знать точный «поток».

Держу пари, что там есть классный инструмент, который можно было бы использовать для непреднамеренного использования. Конечно, могут быть и другие способы. У кого-то есть идея? Благодаря!

ответ

0

Вы можете опробовать Arquillian integration in JBoss Tools. Вы найдете информацию о том, как его использовать, in this GitHub repo; см. README. Связанные с ним скринкасты могут быть полезными.

Чтобы начать работу с JBoss Tools, вы можете установить его в существующий Kepler Eclipse (e4.3) или выше, через сайт обновления JBT, с these instructions.

Обратите внимание, что это считается экспериментальным на данный момент, поэтому он не включен в JBoss Developer Studio (дистрибутив, в который распространяются Eclipse и некоторые плагины), и доступен только в битах сообщества, то есть в JBoss Tools. Мы будем признательны, если вы сообщите о любых проблемах, с которыми вы столкнулись (или какие-либо новые запросы функций) в JBoss Tools JIRA (пожалуйста, используйте компонент тестовых инструментов).

+0

Спасибо! Я посмотрел на репетицию github, и это, кажется, правильный подход. К сожалению, у меня были некоторые общие проблемы с eclipse в прошлом, и кажется, что TestNG еще не поддерживается. Но стоит помнить об этом, может быть, я должен снова попробовать затмение. Было бы здорово, если бы существовала независимая библиотека, которая могла бы использоваться в тестах напрямую (возможно, привязана к аркиллианцу). Извините, я не проголосовал за ваш ответ. Недостаточно репутации ... –

Смежные вопросы