2010-09-15 8 views
17

Voglio implementare JUnit su un piccolo progetto su cui sto lavorando perché voglio imparare un po 'a riguardo.Come posso confrontare i file in un caso di test JUnit?

Le esercitazioni che ho letto tutte fanno riferimento a metodi che hanno un output particolare.

Nel mio caso i miei risultati sono file, come posso fare questo? qualche semplice esempio? qualche approccio che potrebbe aiutarmi con questo?

I file sono file di testo non elaborati creati con un metodo privato vuoto.

+0

Come i metodi di scrittura per il file? Se ottengono un flusso, puoi semplicemente dare loro il tuo anziché uno che punta a un file e quindi confrontarlo. –

+0

Con una stringa di buffer di scrittura di base all'interno di un crawler web (premo invio ma ha scritto il messaggio) il codice è simile a: txtUrlSpecial.write (bigText.charAt (j)); – Saikios

risposta

16

Si desidera ottenere un file di output corretto per un determinato set di input e impostare un test per chiamare il metodo del void con tali input, quindi confrontare il file di output convalidato con quello prodotto dal metodo. Devi assicurarti di avere un modo per specificare dove verrà pubblicato il tuo metodo, altrimenti il ​​test sarà molto fragile.

@Rule 
public TemporaryFolder folder = new TemporaryFolder(); 

@Test 
public void testXYZ() { 
    final File expected = new File("xyz.txt"); 
    final File output = folder.newFile("xyz.txt"); 
    TestClass.xyz(output); 
    Assert.assertEquals(FileUtils.readLines(expected), FileUtils.readLines(output)); 
} 

Utilizza commons-io FileUtils per il testo comodità confronto di file & JUnit di TemporaryFolder per garantire il file di output non esiste prima l'esecuzione del test.

+0

Mi piace, ma perché nessuno vota per la tua risposta? : S – Saikios

+2

Puoi sempre votare per te stesso –

+0

eclipse dice che org.junit.internal.runners.TestClass è deprecato = ( – Saikios

2

Dopo che i metodi hanno scritto il file, nel test dell'unità è possibile leggere il file e verificare se è stato scritto correttamente.

Un'altra cosa che ha senso è dividere i metodi in uno che recupera i dati e li restituisce ai metodi che semplicemente li scrive in un file. Quindi è possibile verificare se i dati restituiti dal primo metodo vanno bene.

E un altro approccio plausibile sarebbe quello di passare un OutputStream al metodo che scrive i dati. Nel "codice reale" è possibile passare uno FileOutputStream/FileWriter, mentre nel codice di prova è possibile scrivere un'implementazione fittizia di OutputStream e verificare cosa viene scritto su di esso.

1

Se non riesci a controllare il metodo per mettere l'output in un flusso, allora direi che devi rifattorizzare il tuo codice in modo che il metodo riceva un flusso nel parametro (o nel costruttore della sua classe) .

Dopodiché, il test è piuttosto semplice: è sufficiente controllare lo stream. Il codice facilmente testabile di solito equivale a un buon codice.

+0

Il problema è che in realtà non crea un singolo file, ma fa tra 3 e 5 file a seconda di cose diverse. Ma siccome sono davvero noob con junit, volevo provarlo prima con un singolo file per capirlo completamente. Grazie = D. – Saikios

+0

@Saikios questo è rilevante per qualsiasi numero di file :) –

1

Anche se la tua domanda può sembrare semplicistica, è fondamentale per il test delle unità, è necessario scrivere codice ben formato che sia verificabile. Questo è il motivo per cui alcuni esperti consigliano di scrivere prima il test unitario e poi la classe di implementazione.

Nel tuo caso suggerisco di consentire al tuo metodo di eseguire e creare i file previsti, in seguito al quale i tuoi test di unità possono analizzare che i file sono formati correttamente.

+0

Grazie, lo avrò in mente per la prossima volta di per prima cosa fai il mio test unitario: D – Saikios

+0

Il codice che scrive l'intero file è probabilmente troppo grande e complesso.JUnit può mostrare se il codice funziona ancora (nessuna regressione) e questo è qualcosa. cosa è rotto. – h22

Problemi correlati