Come testare quando si organizzano i dati è troppo ingombrante?

Sto scrivendo un parser e come parte di ciò, ho una Expanderclasse che "espande" singole istruzioni complesse in più istruzioni semplici. Ad esempio, espanderebbe questo:

x = 2 + 3 * a

in:

tmp1 = 3 * a
x = 2 + tmp1

Ora sto pensando a come testare questa classe, in particolare come organizzare i test. Potrei creare manualmente l'albero della sintassi di input:

var input = new AssignStatement(
    new Variable("x"),
    new BinaryExpression(
        new Constant(2),
        BinaryOperator.Plus,
        new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a"))));

Oppure potrei scriverlo come una stringa e analizzarlo:

var input = new Parser().ParseStatement("x = 2 + 3 * a");

La seconda opzione è molto più semplice, più breve e leggibile. Ma introduce anche una negligenza Parser, il che significa che un bug Parserpotrebbe non superare questo test. Quindi, il test smetterebbe di essere un unit test di Expander, e immagino che tecnicamente diventi un test di integrazione di Parsere Expander.

La mia domanda è: va bene affidarsi principalmente (o completamente) a questo tipo di test di integrazione per testare questa Expanderclasse?

Ti ritroverai a scrivere molti più test, con comportamenti molto più complicati, interessanti e utili, se puoi farlo semplicemente. Quindi l'opzione che comporta

var input = new Parser().ParseStatement("x = 2 + 3 * a");

è abbastanza valido. Dipende da un altro componente. Ma tutto dipende da dozzine di altri componenti. Se prendi in giro qualcosa a meno di un centimetro dalla sua vita, probabilmente stai dipendendo da molte funzionalità di derisione e dispositivi di prova.

A volte gli sviluppatori si concentrano eccessivamente sulla purezza dei loro test unitari o sviluppano solo test unitari e test unitari , senza alcun modulo, integrazione, stress o altri tipi di test. Tutti questi moduli sono validi e utili e sono tutti la responsabilità degli sviluppatori, non solo del Q / A o del personale operativo più avanti.

Un approccio che ho usato è quello di iniziare con queste esecuzioni di livello superiore, quindi utilizzare i dati da esse prodotti per costruire l'espressione di test a forma lunga e con il minimo comune comune del test. Ad esempio, quando si esegue il dump della struttura dei dati dal inputprodotto precedente, è possibile creare facilmente:

var input = new AssignStatement(
    new Variable("x"),
    new BinaryExpression(
        new Constant(2),
        BinaryOperator.Plus,
        new BinaryExpression(new Constant(3), BinaryOperator.Multiply, new Variable("a"))));

tipo di test che verifica al livello più basso. In questo modo ottieni un bel mix: una manciata di test primitivi molto elementari (test unitari puri), ma non hai trascorso una settimana a scrivere test a quel livello primitivo. Questo ti dà la risorsa di tempo necessaria per scrivere molti più, leggermente meno test atomici usando Parsercome aiuto. Risultato finale: più test, più copertura, più corner e altri casi interessanti, codice migliore e garanzia di qualità più elevata.

Certo che va bene!

È sempre necessario un test funzionale / di integrazione che eserciti il ​​percorso completo del codice. E percorso del codice completo in questo caso significa includere la valutazione del codice generato. Cioè test che l'analisi x = 2 + 3 * aproduce codice che se eseguito con a = 5verrà impostato xsu 17e se eseguito con a = -2verrà impostato xsu -4.

Al di sotto di questo, dovresti fare unit test per bit più piccoli purché effettivamente aiuti il ​​debug del codice . I test più precisi che avrai, la maggiore probabilità che qualsiasi modifica al codice debba cambiare anche il test, perché l'interfaccia interna cambia. Tale test ha poco valore a lungo termine e aggiunge lavori di manutenzione. Quindi c'è un punto di rendimenti decrescenti e dovresti fermarti prima.

I test unitari ti consentono di individuare elementi specifici che si rompono e dove nel codice si sono rotti. Quindi sono buoni per test a grana molto fine. Buoni test unitari contribuiranno a ridurre i tempi di debug.

Tuttavia, in base alla mia esperienza, i test di unità raramente sono abbastanza buoni da verificare effettivamente il corretto funzionamento. Quindi i test di integrazione sono utili anche per verificare una catena o una sequenza di operazioni. I test di integrazione ti aiutano a superare i test funzionali. Come hai sottolineato, tuttavia, a causa della complessità dei test di integrazione, è più difficile trovare il punto specifico nel codice in cui si interrompe il test. Ha anche un po 'più di fragilità in quanto i guasti in qualsiasi punto della catena causeranno il fallimento del test. Avrai comunque quella catena nel codice di produzione, quindi testare la catena reale è ancora utile.

Idealmente, avresti entrambi, ma in ogni caso, avere un test automatizzato è meglio che non avere test.

Esegui molti test sul parser e quando il parser supera i test, salva gli output in un file per deridere il parser e testare l'altro componente.