Come testare un lettore di file?

Sto lavorando a un progetto con alcuni formati di file. Alcuni formati sono specificati da .xsds, altri dalla documentazione sui rispettivi siti Web e alcuni sono formati interni personalizzati che non hanno documentazione. Mwahahahaha.

Qual è il problema?

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

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

dove si trova l' FileReaderinterfaccia

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

Il Modelha una serie di attributi che sono popolate quando il file viene letto. Sembra qualcosa del genere

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

Cosa ho provato

La mia unica idea era quella di creare "generatori" di file per ogni formato di file. Questi generatori sono fondamentalmente costruttori che accettano alcune variabili (ad es. Il numero di commenti da generare in un file) e producono un file di esempio che ho poi letto e confrontato il risultante Modelcon le variabili che ho usato per generare inizialmente il file.

Questo ha alcuni problemi, però:

I file che genera non sembrano file reali. Il generatore non è in alcun modo consapevole del contesto.
È difficile riconoscere se il generatore è stato generato per casi limite dal momento che sono io a impostare manualmente le variabili. Questo metodo è appena migliore di me creando una dozzina di file di esempio.

Ci sono modi migliori per farlo?

EDIT: unità modificata per l'integrazione poiché questo è ciò che intendo davvero.

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

Ogni file rappresenta un grafico composto da vertici e bordi. 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 conta la direzione dei bordi. Non sono sicuro che questo rientri nell'ambito della domanda, ma è difficile pensare a tutti i casi relativi ai bordi quando imposto manualmente il numero di vertici, il numero di bordi e genera semplicemente le connessioni in modo casuale.

— sdasdadas
fonte

Vengono in mente test basati sui dati . Potete fornire esempi concreti di casi limite (basati sui casi limite che potrebbero essere attivati nell'attuazione effettiva FileReader)? Esempio: dati i casi limite rilevati nei formati di file di immagine , per ciascuna voce della tabella, se la combinazione di proprietà riga / colonna è supportata, dovrebbe esserci almeno un caso di test (un file di dati) che copre quella combinazione.

— rwong,

@rwong Ho aggiunto un esempio ma non sono sicuro che ti dia un'idea. Immagino che il mio problema sia comune con casi limite, vale a dire. Ne ho perso qualcuno? Tuttavia, i test basati sui dati sembrano interessanti. Grazie!

— sdasdadas,

Inoltre, ho appena notato questo, ma i miei casi limite sono letteralmente casi limite .

— sdasdadas,

Perché non creare file di test artigianali e quindi eseguirli sempre con gli stessi?

— Bobson,

@Bobson È un po 'peggio che usare un generatore. In tal caso, potrei perdere i casi limite (come probabilmente ora mi manca), ma potrei anche introdurre errori nella mia digitazione. E con file enormi, crearli da soli richiederebbe un po 'di tempo.

— sdasdadas,

Innanzitutto, parliamo di quali sono i tuoi obiettivi:

ovviamente non vuoi testare i "formati di file" - vuoi testare le tue diverse FileReaderimplementazioni
vuoi trovare quanti più tipi di errori possibili dai test automatici

Per raggiungere questo obiettivo in pieno, IMHO devi combinare diverse strategie:

in primo luogo, test di unità reali: le FileReaderimplementazioni saranno costituite da molte parti e funzioni diverse. Scrivi piccoli test che testano ciascuno di essi separatamente; progettare le proprie funzioni in modo tale che non siano realmente necessarie per leggere i dati da un file. Questo tipo di test ti aiuterà a testare la maggior parte dei casi limite.
secondo, file generati: quelli sono quelli che definirei test di integrazione. Tali file ti aiuteranno a rintracciare 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 prove del valore al contorno. 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 dal mondo reale: può essere difficile verificare che questi file siano valutati correttamente dai tuoi messaggi FileReader, ma può valerne la pena farlo poiché trova spesso bug non rivelati dalle prime due strategie. Alcune persone chiamerebbero queste cose gentili anche "test di integrazione", altri preferiscono "test di accettazione", ma in realtà il termine non ha importanza.

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

Oltre a ciò, dovresti assicurarti che i tuoi FileReadernon mascherino errori durante la lettura di tali dati: crea assegni / asserzioni incorporati, genera eccezioni quando qualcosa va storto internamente ecc. Questo offre al tuo codice di test una possibilità molto migliore di rilevare errori , anche quando non si dispone di un file di test esplicito o di un caso di test per una situazione imprevista.

— Doc Brown
fonte

Risposta eccezionale, e modificherò il titolo della mia domanda per riflettere meglio. Grazie!

— sdasdadas,