Интеграционные тесты Grails с несколькими службами

Как лучше всего тестировать службу Grails, которая зависит от другой службы? Mixin по умолчанию TestFor правильно внедряет тестируемый сервис, например:

@TestFor(TopService) 
class TopServiceTests {
    @Test
    void testMethod() {
        service.method()
    }
}

но если мой экземпляр TopService (службы) зависит от другой службы, например InnerService:

class TopService {
    def innerService
}

innerService будет недоступен, инъекция зависимостей, похоже, не заполняет эту переменную. Как мне поступить?


unit-testing integration-testing grails grails-2.0
person Wavyx    schedule 13.06.2012    source источник
comment
Попробуйте расширить GroovyTestCase в своем тесте.   -  person    schedule 13.06.2012

Ответы (2)


arrow_upward
8
arrow_downward

Интеграционные тесты не должны использовать аннотацию @TestFor, они должны использовать extend GroovyTestCase. Аннотации тестов предназначены только для модульных тестов (и будут иметь плохое поведение при использовании в интеграционных тестах, особенно аннотации @Mock). Вы сейчас видите одно из этих плохих поступков.

Если вы расширите GroovyTestCase, вы можете просто иметь

def topService

В верхней части вашего теста, и он будет введен со всеми его зависимостями.

Для примера модульного тестирования вы просто хотите добавить новые экземпляры связанных служб в свою службу в методе setUp. Как:

@TestFor(TopService) 
class TopServiceTests {
    @Before public void setUp() {
        service.otherService = new OtherService()
    }
    ...
person Ted Naleid    schedule 13.06.2012
comment
Спасибо! Я наконец понял это с вашим объяснением;) Меня немного ввели в заблуждение комментарии из stackoverflow.com/questions/2272677/ Интеграционные тесты не должны расширять GrailsUnitTestCase. Не уверен, что полностью понимаю разницу между GroovyTestCase и GrailsUnitTestCase... - person Wavyx; 14.06.2012
comment
Самая большая разница (которая в конечном итоге кусает людей) заключается в том, что пример модульного тестирования делает гораздо больше в плане издевательств и возни с метаклассом в setUp и tearDown. Насмешки — это то, в чем интеграционные тесты не нуждаются, поскольку в них уже внедрены реальные вещи. Это также означает, что после завершения интеграционных тестов запускать модульный тест tearDown плохо, так как он может удалить изменения в метаклассе (например, динамические методы GORM), которые должны быть там и которые ожидают последующие интеграционные тесты. - person Ted Naleid; 15.06.2012

arrow_upward
1
arrow_downward

У меня есть CustomerRegistrationServiceTest, и мой CustomerRegistrationService зависит от PasswordService.

мой CustomerRegistrationService просто автоматически подключает его, как обычно:

class CustomerRegistrationService {
    def passwordService

В моем CustomerRegistrationServiceTest у меня есть:

@TestFor(CustomerRegistrationService)
@Mock(Customer)
class CustomerRegistrationServiceTests extends GrailsUnitTestMixin {

    void setUp() {
        mockService(PasswordService)
    }

Поэтому, когда я тестирую CustomerRegistrationService, он может получить доступ к PasswordService.

person klogd    schedule 13.06.2012
comment
Спасибо. Действительно, насмешка кажется подходящим вариантом, но больше для юнит-теста ИМХО. Для интеграционных тестов я бы предпочел протестировать полноценную среду. - person Wavyx; 14.06.2012