2010-05-25 18 views
7

Sto cercando di imparare a scrivere i test. Sto anche imparando Java, mi è stato detto che dovrei imparare/uso/pratica jMock, ho trovato alcuni articoli on-line che aiutano a certa misura come:Come iniziare con il test (jMock)

http://www.theserverside.com/news/1365050/Using-JMock-in-Test-Driven-Development

http://jeantessier.com/SoftwareEngineering/Mocking.html#jMock

E la maggior parte articoli Ho scoperto che avevo a che fare con lo sviluppo basato su test, scrivere prima i test e poi scrivere il codice per far passare il test. Al momento non lo sto cercando, sto provando a scrivere test per codice già esistente con jMock.

Il official documentation è vaga a dir poco e troppo difficile per me. Qualcuno ha modo migliore per imparare questo. Buoni libri/link/tutorial mi aiuterebbero molto. grazie

EDIT - Ancora una domanda concreta:

http://jeantessier.com/SoftwareEngineering/Mocking.html#jMock - da questo articolo

provato questo per deridere questa semplice classe:

import java.util.Map; 
    public class Cache { 
     private Map<Integer, String> underlyingStorage; 
     public Cache(Map<Integer, String> underlyingStorage) { 
      this.underlyingStorage = underlyingStorage; 
     } 
     public String get(int key) { 
      return underlyingStorage.get(key); 
     } 
     public void add(int key, String value) { 
      underlyingStorage.put(key, value); 
     } 
     public void remove(int key) { 
      underlyingStorage.remove(key); 
     } 
     public int size() { 
      return underlyingStorage.size(); 
     } 
     public void clear() { 
      underlyingStorage.clear(); 
     } 
    } 

Ecco come ho cercato di creare un test/finto:

public class CacheTest extends TestCase { 

    private Mockery context; 
    private Map mockMap; 
    private Cache cache; 

    @Override 
    @Before 
    public void setUp() { 
     context = new Mockery() { 
      { 
       setImposteriser(ClassImposteriser.INSTANCE); 
      } 
     }; 

     mockMap = context.mock(Map.class); 
     cache = new Cache(mockMap); 
    } 

    public void testCache() { 
     context.checking(new Expectations() {{ 
      atLeast(1).of(mockMap).size(); 
      will(returnValue(int.class)); 
     }}); 

    } 
} 

supera la prova e in fondo non fa nulla, quello che volevo è quello di creare una mappa e controllare la sua dimensione, e non si sa lavorare alcune variazioni cercano di ottenere una presa su questo. Capire meglio attraverso gli esempi, cos'altro posso testare qui o altri esercizi mi aiuterebbe molto. tnx

+1

Non una risposta, ma: consiglierei di imparare a scrivere i test prima di esaminare i mock. I mock sono un argomento avanzato nei test, devi prima padroneggiare le basi. – Arne

+0

@Arne puoi darmi una risposta concreta a quelle che sono considerate le basi? Sono uno studente veloce, non sto dicendo che sono più intelligente delle altre persone, sono solo impaziente di imparare e ho molto tempo a disposizione. Quindi, se una cosa diventa noiosa, posso passare all'altro semplice/avanzato non importa. tnx – London

+0

Puoi scrivere i tuoi test senza una cornice di derisione. Basta usare JUnit per scrivere i tuoi test. Se stai testando il tuo codice fluentemente e poi incontri un caso che non puoi padroneggiare senza un finto, prova un quadro di derisione. L'esigenza di una simulazione dovrebbe essere l'eccezione, non la regola. – Arne

risposta

5

Ecco un tutorial su come utilizzare JUnit e EasyMock (una libreria beffardo Personalmente trovo molto più facile da usare rispetto JMock): http://www.michaelminella.com/testing/unit-testing-with-junit-and-easymock.html

Anche se sei dedicato al 100% all'utilizzo di JMock, i concetti tra i due sono gli stessi e questo dovrebbe aiutarti a capirli meglio.

Lo scopo di scherno è che quando si prova Classe A, che dipende B e C, il test di A utilizza versioni finte di B e C essere in grado di specificare il loro esatto comportamento piuttosto che utilizzare le reali implementazioni di B e C nel test di A.Altrimenti non si sta testando solo la singola unità di A, si sta testando implicitamente B e C.

+0

puoi/fai falsi costruttori dato che non sono metodi che sto ancora combattendo per capire tutto. – London

+0

Alcune librerie supportano le classi di derisione e non solo le interfacce (EasyMock 3.0 afferma questo) ma non mi è molto familiare. Il mocking brilla quando le classi esprimono dipendenze l'una dall'altra in base a * un'interfaccia * e non a una * classe concreta *. –

1

Non so fino a che punto hai percorso il percorso per imparare a utilizzare gli oggetti mock durante i test, quindi scriverò una breve descrizione quindi ti indicherò la direzione di un articolo che potrebbe essere utile per tu. Gli oggetti fittizi vengono utilizzati nei test delle unità per sostituire dipendenze esterne difficili da creare o difficili da raggiungere nello stato in cui si desiderano per il test. I vari quadri di derisione che esistono ti danno i meccanismi per creare oggetti "falsi" che prendono il posto di queste dipendenze. Questi oggetti mock manterranno traccia delle chiamate che arrivano dal codice e ti permetteranno di fare affermazioni su queste interazioni in seguito. C'è un noto articolo su oggetti mock e come si riferiscono a "stub", un'altra strategia di sperimentazione comune per semplificare le dipendenze esterne. E 'stato scritto da Martin Fowler e può essere trovato qui:

http://martinfowler.com/articles/mocksArentStubs.html

+0

puoi/fai falsi costruttori dato che non sono metodi che sto ancora combattendo per capire tutto. – London

+0

No, il mocking è fatto a livello di classe, quindi il framework mocking gestirà la creazione dell'oggetto "proxy" (cioè, mock) per te. Tieni presente che questo oggetto non implementa il comportamento dell'oggetto che sta deridendo. Lo scopo è di tenere traccia delle interazioni con esso e di verificare che queste interazioni siano avvenute come previsto. –

+0

grazie per la tua spiegazione, come posso testare alcuni di questi metodi? – London

2

Non è necessario davvero prendere in giro per testare questa classe in quanto il suo unico collaboratore è una mappa che si potrebbe anche utilizzare come è. Anche la tua classe in realtà non fa nulla (eccetto i delegati) ed è per questo che ti sembra di non provare molto.

Un test rettilineo potrebbe essere (sto supponendo che si sta utilizzando JUnit 4 - il codice è uno strano miscuglio di JUnit 3 e 4

@Test 
public void sizeIs0WhenEmpty() 
{ 
    Map<Integer, String> map = Collections.emptyMap(); 
    Cache cache = new Cache(map) 
    assertEquals(0, cache.size()); 
} 

con schernisce sarebbe (supponendo che il codice di finto è corretto - io non uso JMock)

@Test 
public void sizeIs0WhenEmpty() 
{ 
    context.checking(new Expectations() {{ 
        atLeast(1).of(mockMap).size(); 
        will(returnValue(0)); 
        }}); 
    assertEquals(0, cache.size()); 
} 

In entrambi i casi si imposta il sistema impostando la mappa per avere le proprietà che si desidera testare e quindi verificare che la cache ha le stesse proprietà (come è un delegato etero)

Si consiglia di leggere about JUnit prima di continuare.

4

Come autore di JMock, non inizierei con la tecnica finché non avessi una certa esperienza con TDD. Inizia dalle basi e fallo funzionare. Una volta che inizi a sperimentare difficoltà con la scala e a far crescere un design, torna alla tecnica.

Il libro di Dave Astels è ancora una buona introduzione e l'unico, penso, di quella generazione che ha spiegato bene i mock. Dopodiché potresti considerare il nostro "Software orientato agli oggetti in crescita guidato da test"

Sconto a chi ti dice che è tutto merito di rendere più rapidi i test sul file system.