Codice Copertura funzioni / parametri generici?

Question

Sto lavorando ad una copertura del codice per le mie applicazioni. Ora so che la copertura del codice è un'attività legata al tipo di test che crei e alla lingua per cui desideri eseguire la copertura del codice.

La mia domanda è: esiste un modo per fare una copertura generica del codice? Come in, possiamo avere una serie di funzionalità / casi di test, che possono essere eseguiti (insieme a test molto più specifici per l'applicazione in prova) per ottenere la copertura del codice, ad esempio il 10% o più del codice?

Più come, se desidero creare un framework per la copertura del codice, qual è il modo migliore per fare uno generico? È possibile avere alcune funzionalità automatizzate o generalizzate?

Answer 1

Non sono sicuro che gli strumenti di copertura generici siano il Santo Graal, per un paio di ragioni:

1. La copertura non è un obiettivo, è uno strumento. Ti dice quali parti del codice non sono interamente colpite da un test. Non dice nulla su quanto sono buoni i test.
2. I test generati non possono indovinare la semantica del tuo codice. I frame che generano test per te possono solo dedurre un significato dalla lettura del tuo codice, che in sostanza potrebbe essere sbagliato, perché l'intero punto di non testamento è vedere se il codice si comporta effettivamente come volevi anche tu.
3. Poiché il framework automatizzato genererà una copertura artificiale, non si può mai dire se un pezzo di codice viene testato con un vero unittest o superficialmente testato da un framework. Preferirei che il codice non testato fosse mostrato come scoperto, quindi lo aggiusto.

Quello che potresti fare (e ho fatto ;-)) è scrivere un test generico per testare i bean Java. Per riflessione, è possibile testare un bean Java rispetto alle specifiche Sun di un bean Java. Asserisci che uguali e hashcode sono entrambi implementati (o nessuno dei due), vedi che il getter restituisce effettivamente il valore che hai inserito con il setter, controlla se tutte le proprietà hanno getter e setter.

Puoi fare lo stesso trucco di base per tutto ciò che implementa " comparabile " per esempio.

È facile da fare, facile da mantenere e ti costringe ad avere fagioli puliti. Per quanto riguarda il resto degli unittest, cerco di concentrarmi sul test delle parti importanti prima e con attenzione.

La copertura può dare un falso senso di sicurezza. Il buon senso non può essere automatizzato.

Answer 2

Questo è generalmente ottenuto combinando l'analisi del codice statico (Coverity, Klockwork o i loro analoghi liberi) con l'analisi dinamica eseguendo un test su un'applicazione strumentata (profiler + controllo della memoria). Sfortunatamente, è difficile automatizzare gli algoritmi di test, la maggior parte degli strumenti sono tipo & Quot; registratori & Quot; in grado di registrare traffico / chiavi / segnali - a seconda del dominio e riprodurli (con modifiche / sostituzioni minime come ID sessione / utente / ecc.)