Generazione del codice dell'unità di test

Bene, l'ho fatto con una struttura gerarchica dei dati dell'albero che ho scritto. La struttura dati analizza un set di dati di input e crea un albero in base a quel set di dati e alle sue relazioni di dati definite.

Ho creato alberi utilizzando vari set di dati di input che sapevo avrebbero adeguatamente coperto i vari casi (ci sono circa sessanta test), serializzato ogni albero in XML e usato quelle stringhe serializzate come risultati attesi per i test unitari, quando ero soddisfatto dell'output XML prodotto da ogni albero.

Funzionava? Sì, abbastanza bene, infatti, e ci è voluto un po 'di tempo in cui avrebbe dovuto scrivere scrupolosamente dei test individuali a mano.

Ci sono degli svantaggi?

1. I test sono abbastanza fragili (si interrompono quando vengono apportate modifiche al codice).
2. Non è sempre chiaro cosa si stia testando esattamente in ogni test, dal momento che non esiste alcuna mappatura dei test ai singoli requisiti.
3. Se un test si interrompe, anche molti altri tendono a rompersi.
4. La diagnosi di un test fallito richiede l'acquisizione dei risultati dei test attesi ed effettivi, incollandoli in un editor di testo e l'esecuzione di un diff per vedere cosa è cambiato.

Come creerai input e output corrispondenti? Da un lato hai l'output prodotto dal codice in fase di test. D'altra parte hai - cosa? L'output di una diversa implementazione dello stesso algoritmo? Questo può aver senso se esiste un algoritmo triviale ma lento che può essere usato per testare un algoritmo più complesso e veloce. O stai andando a bulbo oculare l'output atteso e basta testare contro modifiche indesiderate? In questo caso è molto facile accettare un output non corretto.

Secondo la mia esperienza, i test generati sono preziosi quanto il lavoro che li riguarda.

Non ho mai sentito parlare della generazione dei test unitari. Se fosse possibile, sarebbe usato da tutti. Se qualcosa esiste, sono sicuro che non può darti la garanzia che il tuo codice sia adeguatamente coperto.

Penso che l'approccio migliore per questo tipo di codice legacy sia scrivere test per qualsiasi nuova funzione e qualsiasi nuovo refactoring. I primi passi saranno abbastanza pericolosi per la stabilità dell'applicazione, ma presto sarai il proprietario di una serie relativamente ampia di test.

In questo modo potrebbe essere davvero efficiente perché, in una prima volta, ti troverai di fronte alle parti peggiori del codice (per il necessario refactoring) e alle funzionalità principali (perché saranno influenzate da qualsiasi evoluzione). In questo modo, le sezioni più critiche della tua applicazione verranno trattate rapidamente.

Non otterrai una copertura completa, ma se non hai mai bisogno di tornare a un vecchio pezzo di codice probabilmente significa che questo codice ha una granularità debole con il resto.

Che cosa usi per stimolare il generatore di test unitario?

Si consideri:

int foo(int x, int y)
{
   return (x + y);
}

Il tuo generatore di test di unità può sicuramente generare codice per testare l'aggiunta, ma non ha modo di sapere che quello che volevi veramente era una moltiplicazione. Ho visto qualcosa del genere mordere un mio collega molto male parecchi anni fa. Stavamo usando Ada, facendo sovraccaricare l'operatore per imporre l'analisi dimensionale alla nostra aritmetica. Ha inciso il nome di "+" per quattro volte e ha cambiato l'operatore a sinistra, ma non a destra. Gli è costato un po 'di lacrimazione per capire perché la sua routine moltiplicata stava restituendo somme anziché prodotti. (Questo ti protegge dal cercare di aggiungere una velocità e una distanza, che per definizione è priva di significato.)