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.

È stato utile?

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).

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top