2012-06-13 5 views
5

Qual è la migliore pratica per provare un servizio Grails che dipende da un altro servizio? Il mixin predefinita TestFor correttamente iniettare il servizio in prova, per esempio:Test di integrazione di Grails con più servizi

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

ma se la mia istanza di Topservice (servizio) si basa su un altro servizio, come InnerService:

class TopService { 
    def innerService 
} 

innerService non sarà disponibile, l'iniezione di dipendenza non sembra riempire questa variabile. Come dovrei procedere?

+0

Provare a estendere 'GroovyTestCase' nel test. –

risposta

8

I test di integrazione non devono utilizzare l'annotazione @TestFor, devono essere extend GroovyTestCase. Le annotazioni di prova sono solo per test di unità (e avranno un comportamento errato quando vengono utilizzate nei test di integrazione, in particolare le annotazioni @Mock). Stai vedendo uno di quei cattivi comportamenti ora.

Se si estende GroovyTestCase si può quindi semplicemente

def topService 

Nella parte superiore della vostra prova e avrai iniettato con tutte le dipendenze che sia iniettato.

Per un caso di test unitario, si desidera semplicemente aggiungere nuove istanze di servizi associati al servizio in un metodo setUp. Proprio come:

@TestFor(TopService) 
class TopServiceTests { 
    @Before public void setUp() { 
     service.otherService = new OtherService() 
    } 
    ... 
+0

Grazie! Finalmente l'ho capito con la tua spiegazione;) Ero un po 'fuorviato dai commenti da http://stackoverflow.com/questions/2272677/dependency-injection-in-grails-integration-tests "I test di integrazione non dovrebbero estendere GrailsUnitTestCase" . Non sono sicuro di avere le differenze tra GroovyTestCase e GrailsUnitTestCase ... – Wavyx

+1

La differenza più grande (che finisce per mordere le persone) è che il caso di test unitario fa molto di più nel modo di burlarsi e scherzare con la metaClass su setUp e tearDown. Il mocking è qualcosa che i test di integrazione non hanno bisogno dato che hanno già iniettato cose reali. Significa anche che quando i test di integrazione terminano, è brutto che il test di unità tearDown venga eseguito in quanto può rimuovere le modifiche alla metaClass (come i metodi GORM dinamici) che dovrebbero essere lì e che i successivi test di integrazione si aspettano. –

1

Ho un CustomerRegistrationServiceTest e il mio CustomerRegistrationService dipende da PasswordService.

mia CustomerRegistrationService proprio autowires piace normale:

class CustomerRegistrationService { 
    def passwordService 

Nel mio CustomerRegistrationServiceTest ho:

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

    void setUp() { 
     mockService(PasswordService) 
    } 

Così, quando ho testare il CustomerRegistrationService, è in grado di accedere al PasswordService

+1

Grazie. In effetti, il mocking sembra essere la strada da percorrere, ma di più per un IMHO di unit test. Per i test di integrazione preferisco testare l'ambiente completo. – Wavyx