È eccessivo eseguire il test unitario con Valgrind?
-
19-08-2019 - |
Domanda
Solo qualche giorno fa ho iniziato a esaminare un framework di unit test chiamato check, e intendo eseguire il test su codice c sotto Linux.
Ora controlla e un po 'di codice ben progettato e un po' di codice di prova possono aiutarmi a verificare che la funzionalità di base sia corretta, Voglio dire, è abbastanza facile guardare semplicemente le variabili e la risposta indietro e poi decidere se una funzione è corretta o meno.
Ma diciamo che voglio testare una struttura di memoria dinamica con molto malloc e gratis, e si scopre che posso inserire i dati e ottenere nuovamente i dati corretti. Ma ciò non prova che non ho rotto un po 'di memoria nel processo, diciamo che ho dimenticato di liberare metà della memoria e ho perso i puntatori (un memleak classico). Tale codice probabilmente supererebbe la maggior parte dei test unitari.
Quindi ora per la domanda: è una buona idea eseguire l'intero codice di test unitario con Valgrind e lasciarlo fare rilevare eventuali problemi malloc / liberi? (O forse compilare qualcosa come Electric Fence?)
Sembra una buona idea, ma non sono sicuro di cosa mi sto prendendo qui .....
Grazie Johan
Aggiornamento: Grazie Douglas e Jonathan, sembra che questa sia una buona idea e qualcosa con cui dovrei continuare :-)
Aggiornamento: Valgrind è uno strumento divertente, tuttavia i primi memleaks che ho trovato facendo questo era nel framework di test e non nel mio codice (abbastanza divertente però). Quindi un suggerimento per il resto è verificare che il framework di unit test che si sta utilizzando non abbia perdite, prima di capovolgere il proprio codice. Un caso di test vuoto era tutto ciò che serviva nel mio caso, da allora non è in esecuzione altro che il framework di unit test.
Soluzione
Certamente, è molto più semplice eseguire valgrind contro i test unitari che con il programma completo.
Inoltre, eventuali errori di memoria sono localizzati nell'area di codice che l'unità sta testando, il che semplifica la correzione.
Inoltre, verificare che sia stato risolto è più semplice, poiché si esegue il test unitario non un test più complicato rispetto al programma completo.
Se stai eseguendo valgrind in modo automatizzato, probabilmente vuoi --error-exitcode=<number> [default: 0]
Specifica un codice di uscita alternativo da restituire se Valgrind ne ha segnalato uno errori in fuga. Se impostato su valore predefinito (zero), il valore restituito da Valgrind sarà sempre il restituisce il valore del processo simulato. Se impostato su un valore diverso da zero valore, tale valore viene invece restituito, se Valgrind rileva errori. Questo è utile per usare Valgrind come parte di una suite di test automatizzata, dal momento che semplifica il rilevamento di casi di test per che Valgrind ha segnalato errori, semplicemente controllando i codici di ritorno.
http://valgrind.org/docs/manual/ manual-core.html # manual-core.erropts
Altri suggerimenti
Come ha detto Douglas Leeder, vale la pena eseguire i test unitari con qualsiasi software diagnostico che si possa imporre per garantire che funzioni davvero come previsto. Ciò include non abusare della memoria, quindi usare valgrind è una buona idea.
Vuoi davvero che i tuoi test unitari dimostrino che il tuo codice funziona.
Non devi eseguirli sempre sotto valgrind, ma dovrebbe essere il più banale possibile farlo, e dovresti farlo periodicamente (diciamo dopo grandi cambiamenti).