Come si usa l'iniezione a molla per l'unità che testa un controller?

Question

Voglio testare il mio controller mvc a molla.

Il controller dispone di un servizio:

@Autowired 
UserService userService 

E il mio servizio per l'utente dipende (autowired) il mio UserDao e alcuni altri servizi come MongoDB ecc

Ora voglio la logica di business per essere testato in il mio UserService, ma naturalmente voglio prendere in giro le risposte dal mio UserDao e da Mongodb, ecc.

Come si configura correttamente il test dell'unità?

Posso riutilizzare il file xml del contenitore primavera che contiene tutti i miei bean ecc. Oppure ne creo uno nuovo? (presumo che debba coinvolgere il contenitore della molla qui)

In cerca di indicazioni su questo, qualsiasi tutorial sarebbe molto apprezzato.

Aggiornamento

Quello che trovo strano è che per il mio controller di primavera (che non implementa dal Controller) sono stato in grado di accedere al mio varialbe privato a impostare manualmente il mio servizio, vale a dire:

@Controller 
public class UserController { 

    @Autowired 
    UserService userService; 
} 

E nel mio test di unità che potevo fare:

UserController controller = new UserController(); 
controller.userService = .... 

Ma per il mio UserService, che ha UserDao autowired, io non può accedere la proprietà userDao:

UserService userService = new UserServiceImpl(); 
userService.userDao = .... // not available 

Ha senso poiché è privato, ma come funziona per il mio controller?

Answer 1

Il framework Spring ha caratteristiche molto interessanti per il test. Puoi dare un'occhiata a Spring reference guide. Può fornire DI anche nella classe di test JUnit.

@RunWith(SpringJUnit4ClassRunner.class) 
// ApplicationContext will be loaded from "/applicationContext.xml" and "/applicationContext-test.xml" 
// in the root of the classpath 
@ContextConfiguration(locations={"/applicationContext.xml", "/applicationContext-test.xml"}) 
public class MyTest { 
    // class body... 
} 

In breve, è possibile utilizzare il proprio applicationContext.xml o anche definirne uno nuovo solo per i test. Personalmente ne uso uno diverso poiché definisco un altro DataSource dedicato a scopi di test.

Answer 2

Quello che trovo strano è che per il mio controller di primavera (che non implementa dal Controller) sono stato in grado di accedere al mio varialbe privato a impostare manualmente il mio servizio, vale a dire:

Questo è facile : la varible in non privato.

Ha la visibilità predefinita ("pacchetto privato"). Ciò significa che puoi accedervi da tutte le classi dello stesso pacchetto.

Quindi, se si dispone di una struttura comune, il controller e il test case del controller si trovano nello stesso pacchetto. Pertanto è possibile modificare i campi del controller ("pacchetto privato"). Ma il caso di test del controller e il servizio non sono nella stessa confezione, quindi non è possibile accedere ai campi del servizio ("pacchetto privato").

Answer 3

Posso riutilizzare il file xml del contenitore primavera che contiene tutti i miei fagioli o devo crearne uno nuovo? (Sto assumendo che devo ottenere il contenitore di primavera coinvolto qui)

Vorrei consigli contro la creazione di nuovo file XML. Si finirebbe per duplicare molte cose e sarà difficile da mantenere. Ci sarebbe proliferazione di file di configurazione. Metti la configurazione richiesta per i test in un diverso xml e questo non dovrebbe nemmeno essere distribuito nella tua scatola di produzione. Per quanto riguarda l'utilizzo della configurazione per i bean, è possibile utilizzare il meccanismo come suggerito da @Trein.

Per il test di primavera contrller in generale, si può anche trovare questo SO Thread utile.

Spero che questo aiuti.