Ti riferisci alla copertura del codice da test di unità o codice stantio? Generalmente penso che solo il codice verificabile che ha un fallimento dovrebbe essere coperto con un test unitario (sì, mi rendo conto che potrebbe essere l'inizio di una guerra santa, ma è qui che mi trovo). Quindi sarebbe una percentuale piuttosto bassa.
Ora il codice stantio d'altra parte è una storia diversa. Il codice obsoleto è un codice che non viene utilizzato. Molto probabilmente non hai bisogno di uno strumento per dirti questo per molto del tuo codice, basta cercare i piccoli punti blu dopo la compilazione in Delphi. Qualcosa senza un punto blu è stantio. Generalmente, se il codice non viene utilizzato, dovrebbe essere rimosso. Quindi sarebbe la copertura del codice al 100%.
Ci sono altri scenari per il codice stantio, come se si avesse un codice speciale da gestire se la data dovesse mai arrivare il 31 di febbraio. Il compilatore non sa che non può accadere, quindi lo compila e gli dà un punto blu. Ora puoi scrivere un test unitario per questo, e testarlo e potrebbe funzionare, ma poi hai appena sprecato il tuo tempo una seconda volta (prima scrivendo il codice, secondo per testarlo).
Esistono strumenti per tenere traccia di quali percorsi di codice vengono utilizzati durante l'esecuzione del programma, ma questo è solo simi-affidabile poiché non tutti i percorsi di codice verranno utilizzati ogni volta. Come quel codice speciale che devi gestire bisestile, verrà eseguito solo ogni quattro anni. Quindi, se lo togli, il tuo programma verrà interrotto ogni quattro anni.
Immagino di non aver risposto alla tua domanda su DUnit e la copertura del codice, ma penso che avrei potuto lasciarti altre domande con cui hai iniziato. Che tipo di copertura del codice stai cercando?
AGGIORNAMENTO: Se si sta adottando un approccio TDD, non viene scritto alcun codice fino a quando non si scrive un test per esso, quindi per sua natura sono disponibili 100 test di copertura. Ovviamente solo perché ogni metodo è esercitato da un test non significa che viene esercitata tutta la sua gamma di comportamenti. SmartInspect fornisce un metodo davvero semplice per misurare quali metodi vengono chiamati insieme al tempo, ecc. È un po 'meno di AQTime, ma non è gratuito. Con un po 'più di lavoro da parte tua puoi aggiungere strumenti per misurare ogni percorso di codice (rami di istruzioni "if", ecc.) Naturalmente puoi anche aggiungere la tua registrazione ai tuoi metodi per ottenere un rapporto di copertura, e questo è gratuito (beh, aspettati il tuo tempo, che probabilmente vale più degli strumenti). Se usi JEDI Debug, puoi anche ottenere uno stack di chiamate.
TDD non può essere applicato facilmente retroattivamente al codice esistente senza un sacco di refactoring. Sebbene i più recenti IDE Delphi abbiano la possibilità di generare stub di test unitari per ogni metodo pubblico, che fornisce quindi una copertura del 100% dei metodi pubblici. Quello che metti in quei tronchi determina quanto sia efficace quella copertura.
Non ho ancora accettato una delle risposte, perché voglio incoraggiare le persone a scrivere la loro opinione sui test unitari, quali strumenti usano e quale copertura cercano di ottenere. Quindi tutti, sentitevi liberi di commentare;) – jpfollenius