2011-04-08 14 views
5

Ho un'applicazione molla e voglio creare un test unitario su un controller come questo. Il problema è che la classe Wrapper è una classe interna privata, quindi Wrapper non è compreso nel test. È possibile deriderlo con Mockito senza cambiare la classe del controller. Posso usare prepareData() per ottenere un'istanza dell'oggetto, ma non so se questo potrebbe essere usato per deridere quell'oggetto.Come prendere in giro una classe interna privata

Grazie

@Controller 
public class Controller { 

    private class Wrapper { 
     private Object1 field1; 
     private Object2 field2; 
     private Object1 method1(){ 
      ... 
     } 
     private Object2 method1(){ 
      ... 
     } 
    } 

    @ModelAttribute("data") 
    public Wrapper prepareData() { 
      return new Wrapper(); 
} 

    public String save(@ModelAttribute("data") Wrapper wrapper, BindingResult result, Model model){ 
     ... 
    } 
} 

Quindi, nel mio test vorrei avere qualcosa di simile

@Test 
public void usernameEmpty(){ 

    BindingResult result = Mockito.mock(BindingResult.class); 
    Model model = Mockito.mock(Model.class); 
    Wrapper data = //how to mock it 
    when(data.method1()).then(new Foo1()); 
    when(data.method2()).then(new Foo2()); 
    String returned = controller.save(data, result, model); 
    .... 
} 
+3

Chiedo perché vuoi farlo? Probabilmente finirai per testare il codice sbagliato. Se la classe interiore ha delle dipendenze (probabilmente ottenute attraverso il controllore?) Deride quelle. Aspettare? Il tuo codice viene compilato? Se Wrapper è una classe privata, puoi usarlo come argomento per un metodo pubblico? –

+0

@ Martininho Fernandes Sono nuovo nei test. Volevo solo fare un test sul metodo di salvataggio, quindi ho dovuto prendere in giro l'oggetto Wrapper in modo da poter definire gli oggetti di ritorno quando alcuni metodi sono stati invocati su di esso. Sì, il controller compila (il test non fa ma questo è il problema - che non posso usare la classe Wrapper nel test). Forse c'è un modo migliore per farlo. – Javi

+0

Java mi ha appena sorpreso di nuovo (sul negativo). Questo mi rende impotente ad aiutare senza un compilatore Java a portata di mano :(Comunque, anche se permesso, non penso che sia un buon progetto avere un metodo pubblico che richiede la conoscenza dei privati, rompendo l'incapsulamento. usare questo metodo nel vero codice reale? È possibile? –

risposta

8

Il test è sui metodi, ma mette alla prova tutto il comportamento della classe. Se la tua classe interiore è privata, allora è un dettaglio di implementazione. Qualcosa che il test non dovrebbe sapere. C'è un sacco di comportamenti in quella classe interiore e tu vuoi testarlo indipendentemente forse dovresti renderlo pubblico e separato da questa classe.

Forse tu pensi: ma poi ... è un sacco di codice da testare (una cosa molto grande indivisibile), non posso testare qualcosa di più piccolo? Beh si. Test Driven Development mandati per realizzare un'implementazione minima e aggiungere più codice solo se aggiungi altri test. Quindi inizi con alcuni test e un'implementazione minima ed evolvi entrambi finché i test non avranno tutte le specifiche e il codice di tutte le implementazioni.

Quindi non preoccuparti delle classi interne private. Metti alla prova il tuo contratto di classe!

+0

E buona fortuna con i test delle unità! Dà molta fiducia e la capacità di cambiare senza (involontariamente) rompere la cosa! – helios

+0

Non è molto buono - sarà un test di integrazione. Hai rotto uno dei principi fondamentali dello sviluppo basato sui test: il test dovrebbe essere semplice! – user710818

+0

Sì. Ma TDD è una metodologia di sviluppo: prima scrivi test, poi scrivi codice. In tal caso, l'OP potrebbe ottenere un altro design (più semplice e più modulare) e non ottenere una classe interna privata. In questa situazione sta solo testando un codice già esistente. Detto questo: sono d'accordo non è un test semplice ma una classe interna privata non è estraibile dalla classe contenitore, quindi non è semplice, non è un test di integrazione IMHO (comunque, la parte importante è "test" :) – helios

Problemi correlati