Misurazione della copertura del codice in Delphi

Question

Esiste un modo per misurare la copertura del codice con DUnit?Oppure ci sono strumenti gratuiti che riescono a farlo?Cosa usi per quello?Quale copertura del codice scegli di solito?

Jim McKeeth:Grazie per la risposta dettagliataSto parlando di unit test nel senso di un approccio TDD, non solo di unit test dopo che si è verificato un guasto.Sono interessato alla copertura del codice che posso ottenere con alcuni unit test di base prescritti.

Answer 1

Ho appena creato un nuovo progetto open source su Google Code con uno strumento di copertura del codice di base per Delphi 2010. https://sourceforge.net/projects/delphicodecoverage/

Al momento è in grado di misurare la copertura della linea, ma ho intenzione di aggiungere anche la copertura di classi e metodi.

Genera report HTML con un riepilogo e una fonte contrassegnata che mostra quali linee sono coperte (verdi), quali non lo erano (rosse) e il resto delle linee per le quali non è stato generato alcun codice.

Aggiornamento:A partire dalla versione 0.3 del Copertura del codice Delphi puoi generare report XML compatibili con il plug-in Hudson EMMA per visualizzare le tendenze di copertura del codice all'interno Hudson.

Aggiornamento:La versione 0.5 apporta correzioni di bug, maggiore configurabilità e report ripuliti

Aggiornamento:La versione 1.0 offre il supporto per l'output di emma, la copertura di classi e metodi e la copertura di DLL e BPL

Answer 2

Non so di eventuali strumenti gratuiti. AQTime è quasi lo standard de facto per la profilatura Delphi. Non ho usato, ma una rapida ricerca trovato Discover per Delphi , che ora è open source, ma proprio non copertura del codice.

Uno di questi strumenti dovrebbe darvi un'idea di quanto il codice di copertura il test di unità sono sempre.

Answer 3

Si riferisce alla copertura del codice da test di unità o il codice stantio? In generale penso che solo codice verificabile che ha un fallimento dovrebbe essere coperto con una prova di unità (sì mi rendo conto che può cominciare una guerra santa, ma che è dove mi trovo). In modo che sarebbe una percentuale piuttosto bassa.

Codice Ora stantio d'altra parte è una storia diversa. Codice stantio è il codice che non viene utilizzato. Molto probabilmente non è necessario uno strumento per dirvi questo per un sacco di codice, basta guardare per i più piccoli puntini blu dopo la compilazione in Delphi. Tutto ciò senza un punto blu è stantio. Generalmente se il codice non viene utilizzato allora dovrebbe essere rimosso. In modo che sarebbe copertura del codice 100%.

Non ci sono altri scenari per il codice stantio, come se si dispone di codice speciale per gestire se la data mai atterra il 31 di febbraio. Il compilatore non sa che non può accadere, in modo che lo compila in e gli dà un punto blu. Ora è possibile scrivere uno unit test per questo, e testarlo e potrebbe funzionare, ma poi basta sprecato il vostro tempo per la seconda volta (la prima per la scrittura del codice, secondo per testarlo).

Ci sono strumenti per monitorare ciò che i percorsi di codice vengono utilizzati quando il programma viene eseguito, ma che è solo simi-affidabile in quanto non tutti i percorsi di codice si abituerà ogni volta. Come quel codice speciale si deve gestire anno bisestile, che verrà eseguito solo ogni quattro anni. Quindi, se si tira fuori allora il programma sarà rotto ogni quattro anni.

Credo che non ho davvero rispondere alla tua domanda su dunit e Code Coverage, ma penso che potrebbe aver lasciato con più domande poi si è iniziato con. Che tipo di copertura di codice stai cercando?

UPDATE: Se state prendendo un approccio TDD allora nessun codice è scritto fino a quando si scrive un test per essa, quindi per sua natura si dispone di 100 copertura di test. Naturalmente solo perché ogni metodo è esercitata da un test non significa che la sua intera gamma di comportamenti viene esercitato. SmartInspect fornisce un metodo molto semplice per misurare i metodi richiamati insieme temporizzazione, ecc E ' un po 'meno poi AQTime, ma non libero. Con un po 'più di lavoro da parte vostra è possibile aggiungere la strumentazione per misurare ogni percorso di codice (rami di "if", ecc) Naturalmente si può anche solo aggiungere il proprio registrazione per i vostri metodi per ottenere un rapporto di copertura, e che è gratuito (beh, si aspettano per il vostro tempo, che è probabilmente vale più quindi gli strumenti). Se si utilizza JEDI Debug allora si può ottenere uno stack di chiamate troppo.

TDD in realtà non può essere facilmente applicata retroattivamente al codice esistente senza un sacco di refactoring. Anche se i più recenti Delphi IDE hanno la capacità di generare dei test di unità per ogni metodo pubblico, che poi ti dà una copertura del 100% dei vostri metodi pubblici. Ciò che si mette in quei mozziconi determina quanto efficace che la copertura sia.

Answer 4

Discover per Delphi e lo fa il lavoro, per l'unit testing con dunit e collaudo funzionale con TestComplete.

Alla scoperta può essere configurato per eseguire dalla riga di comando per l'automazione. Come in:

Discover.exe Project.dpr -s -c -m

Answer 5

Scopri grandi opere per me. E 'difficilmente rallenta l'applicazione, a differenza di AQTime. Questo potrebbe non essere un problema per voi in ogni caso, naturalmente. Credo che le versioni recenti di AQTime un rendimento migliore in questo senso.

Answer 6

Ho usato Discover" per anni, ha lavorato in modo eccellente fino al BDS2006 (che era l'ultima pre-XE * versione di Delphi ho usato e usano ancora), ma il suo stato attuale opensourced, non è chiaro come fare il lavoro con XE * versioni di Delphi. Un vero peccato, perché ho amato questo strumento, veloce e conveniente in quasi ogni modo. Così ora sto muovendo a Delphi-code-coverage ...