Come faccio a testare un lettore di file?

18

Sto lavorando su un progetto con pochi formati di file. Alcuni formati sono specificati da .xsds, altri dalla documentazione sui rispettivi siti Web e alcuni sono formati interni personalizzati senza documentazione. Mwahahahaha.

Qual è il problema?

Vorrei testare i miei lettori di file, ma non sono del tutto sicuro su come procedere. Il flusso dell'applicazione è come tale:

file.___  ===> read by FileReader.java ===> which creates a Model object

dove l'interfaccia FileReader è

public interface FileReader {
    public Model read(String filename);
}

Il Model ha un numero di attributi che vengono popolati quando il file viene letto. Assomiglia a

public class Model {
    List<String> as;
    List<String> bs;
    boolean isAPain = true;
    // ...
}

Che cosa ho provato?

La mia unica idea era di creare file "generatori" per ogni formato di file. Questi generatori sono fondamentalmente dei builder che contengono alcune variabili (ad esempio il numero di commenti da generare in un file) e generano un file di esempio che poi ho letto e confrontano il risultante Model con le variabili che ho usato per generare inizialmente il file.

Questo ha alcuni problemi, però:

  • I file che genera non guardano come i file reali. Il generatore non è in alcun modo a conoscenza del contesto.
  • È difficile riconoscere se il generatore ha generato per i casi limite poiché io sono quello che imposta manualmente le variabili. Questo metodo è appena migliore di me nella creazione di una dozzina di file di esempio.

Ci sono modi migliori per farlo?

EDIT: modifica l'unità di integrazione poiché questo è ciò che intendo realmente.

EDIT2: Ecco un esempio dei casi limite che ho citato.

Ogni file rappresenta un grafico costituito da vertici e spigoli. Questi vertici e bordi possono essere collegati in diversi modi, quindi:

v1 -- e1 --> v2 <-- e2 -- v3

è diverso da

v1 -- e1 --> v2 -- e2 --> v3

in quanto la direzione dei bordi è importante. Non sono sicuro se questo è nel campo di applicazione della domanda, ma è difficile pensare a tutti i casi limite pertinenti quando imposto manualmente il numero di vertici, il numero di spigoli e solo a generare le connessioni casualmente.

    
posta sdasdadas 23.09.2013 - 18:24
fonte

1 risposta

18

In primo luogo, parliamo dei tuoi obiettivi:

  • ovviamente non vuoi testare "formati di file" - vuoi testare le diverse implementazioni FileReader

  • vuoi trovare quanti più tipi di errori possibili con i test automatici

Per raggiungere l'obiettivo per intero, IMHO devi combinare diverse strategie:

  • primo, test delle unità reali: le tue implementazioni FileReader consisteranno in molte parti e funzioni diverse. Scrivi piccoli test che testano ciascuno di loro in isolamento; progetta le tue funzioni in un modo in cui non hanno realmente bisogno di leggere i dati da un file. Questo tipo di test ti aiuterà a testare la maggior parte dei tuoi casi limite.
  • secondo, file generati: quelli sono quelli che chiamerei test di integrazione. Tali file ti aiuteranno a rintracciare i guasti diversi dal punto 1, ad esempio combinazioni di parametri specifici, errori nell'accesso ai file, ecc. Per creare buoni casi di test, sarà anche utile conoscere alcune tecniche classiche come raggruppare i casi di test in classi di equivalenza o test del valore limite. Ottieni una copia di questo libro di Glenford Myers per saperne di più. Anche l' articolo di Wikipedia sui test del software è una buona risorsa.
  • terzo, cerca di ottenere dati del mondo reale: può essere difficile verificare che questi file siano valutati correttamente dal tuo FileReader s, ma potrebbe valerne la pena, dato che spesso trova bug non rivelati dal prime due strategie. Alcune persone chiamerebbero questo genere di cose anche "test di integrazione", altri preferiscono "test di accettazione", ma in realtà il termine non ha molta importanza.

IMHO non esiste un approccio "scorciatoia" che ti porti il beneficio di tutte e tre le strategie "al prezzo di una". Se si desidera rilevare casi limite e guasti nei casi standard, nonché casi reali, è necessario investire almeno un po '- probabilmente molto altro - sforzo. Fortunatamente, tutti questi approcci possono essere utilizzati per creare test automatici ripetibili.

Oltre a ciò, dovresti assicurarti che FileReader s non copra alcun errore durante la lettura di quei dati - crea controlli / asserzioni in-built, genera eccezioni quando qualcosa va storto internamente ecc. Questo dà al tuo codice di test un possibilità molto migliori di rilevare errori, anche quando non si dispone di un file di test esplicito o di un caso di test per una situazione inaspettata.

    
risposta data 24.09.2013 - 08:18
fonte