Newsgroup: it.comp.www.php
Titolo: code coverage

xdebug_start_code_coverage( XDEBUG_CC_UNUSED | XDEBUG_CC_DEAD_CODE );
 
function a($a) {
     echo $a * 2.5;//non eseguita
}
 
function b($count) {
     for ($i = 0; $i < $count; $i++) {
         a($i + 0.17);
     }
}
 
b(10);
 
print_r(xdebug_get_code_coverage());
 
Si ottiene
 
Array
         (
             [4] => 1
             [5] => 1
             [6] => 1
             [8] => 1
             [9] => 1
             [10] => 1
             [12] => 1
             [14] => 1
             [16] => 1
         )
 
Ma perchè viene indicato ***[5] => 1*** che anche la riga 5 viene eseguita?

 Ma perchè viene indicato ***[5] => 1*** che anche la riga 5 viene eseguita?
 
Da quel che vedo io viene eseguita 10 volte...
 
Bye.
 


mi sa che hai visto male.
cmq piccola precisazione: alla riga 1 ci sarebbe il tag <?php che ho 
omesso...


 
Ha visto bene.
 
Ciao!

 Ha visto bene.
 
chiedo scusa, ma allora le funzioni in oggetto a cosa servono?
in pratica io vorrei sapere quali righe sono/nonSono state eseguite...


e mi sa anche che di deve seguire ciò che c'è scritto qui
https://phpunit.de/manual/current/en/code-coverage-analysis.html
 
 
Ma bisogna per forza creare test-case con appositi doc-blocks?

alex <1j94...@lnx159sneakemail.com.invalid> ha scritto:

..E magari la prossima volta posta il codice con i numeri
di riga, per onorare la precisione e per avere un riscontro
più facile...
 
 


Sostanzialmente, sì.
 
Poi è lavoro che ti ritrovi, credimi :-)
 
Consideralo un investimento.
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

 Consideralo un investimento.
 
anche se è probabile che in futuro queste funzionalità saranno già 
integrate in php, senza installare pacchi extra :)


 
Ho dimenticato la prima riga, e cmq ho messo il commento alla riga non 
eseguita


Non credo: la scelta dei meccanismi di testing dipendono dal processo di
sviluppo, che è diverso da azienda a azienda. :)
 
Ciao!

 Ma bisogna per forza creare test-case con appositi doc-blocks?
 
No. I docblock servono se vuoi disattivare il code coverage per alcuni 
test. PHPUnit si interfaccia automaticamente (o quasi) con xdebug per 
calcolare il code coverage dei test.
 
Creare test è praticamente obbligatorio quando il tuo codice inizia a 
crescere di dimensioni, ma ti conviene iniziare quando è piccolo per non 
trovarti a scrivere centinaia di test in un colpo solo, che 
obiettivamente è abbastanza noioso.
 
In alcuni casi è conveniente addirittura scrivere i test prima del 
codice, anche se io non sono un grande fan di questa metodologia.
 
Non verrà integrato in PHP perché ci sono decine di test framework, con 
pro e contro, e non avrebbe senso integrarne uno per lasciare fuori tutti 
gli altri.
 
Bye.


inserire qualche funzione ad uso immediato tipo covered_lines() non 
sarebbe cmq male, a prescindere...


 
Cosa c'entrano i test-framework?
Come già detto, è bene che nelle future versioni, php integri funzioni 
di code-covering a prescintere dal TF che si adrà ad usare (io me lo 
sono autocostruito).
Del resto, funzioni di debugging come var_dump, print_r, 
debug_backtrace, ecc. sono già disponibili senza installare/importare 
nient'altro.
 


 
La code coverage è una misura relativa ad una specifica test suite, quindi non
ha molto senso senza avere un test framework (per quanto minimale o generico
possa essere).
 
Ciao!


 
Forse ho dimenticato di commentare la call dentro il for, chiedo scusa.
Ad ogni modo, se volessi avere solo i numeri delle righe non eseguite?


Stando alla documentazione qui:
https://xdebug.org/docs/code_coverage
 
passi alla xdebug_start_code_coverage() XDEBUG_CC_UNUSED | XDEBUG_CC_DEAD_CODE
e conti i -1 e -2, a seconda di cosa cerchi.
 
Comunque, per te, per il futuro: le domande sono sempre ben accette, ma se uno
che sa la risposta ha il dubbio che il domandante non ha fatto le sue ricerche
da solo, o non ha neppure controllato i suoi post dopo che glielo si è fatto
notare, difficilmente risponderà.
Per questo molti thread qui non hanno seguito: non che non ci sia nessuno che
legge che sappia cosa dire, ma spesso non ha voglia di replicare perché pensa
sia inutile.
 
Ciao!

 sia inutile.
 
Troppe cose da fare...
Hai totalmente ragione, ma non è per svogliataggine, bensì per 
tutt'altro: come appena accennato, troppo lavoro non aiuta a concentrarsi.
Pardon :D
 


 
Sono contento che non l'hai presa come una critica, perché assolutamente non
lo era! :) Anch'io faccio centinaia di post su NG che trattano di cose che non
mastico per nulla (su ism, fisf, ihe o ihs per esempio di sicuro non ho una buona
fama :D ). A volte quando so l'argomento faccio il saccente, ma negli anni ho
dovuto cercare di trovare un modo di scrivere i post che faccia venir voglia
di rispondere alle cose che non so..
 
Alla fine è solo questione di forma, visto che sulla sostanza sono tutti sempre
pronti a dire la loro! ;)
 
Ciao!


 
Vedi che nonostante sono stordito dal lavoro, qualcosa che non va c'è 
d'avvero?
E cmq se *qualcuno* parlava di integrare alcune funzioni nel 
compilatore, forse un motivo c'è.
 
 


 
Ho letto la risposta solo adesso (o l'avevo letta ma ero troppo ubriaco per
rispondere, e poi mi son scordato :) ).
 
Questa funzionalità, ovvero quella di sapere quali righe hanno girato e quali
no, mica è uno scherzo: è tecnicamente il classico paletto in quel posto, sia
dal punto di vista teorico che pratico.
 
Cominciamo a dire che non è possibile farlo a compile time, tantomeno con un
check statico. Non è possibile per un motivo *matematico*. Il problema di
sapere se una riga è stata eseguita o no è riducibile al problema della
terminazione (che come tutti sappiamo è stato dimostrato indecidibile da
Turing - se non sapete come sia riconducibile dateci un'occhiata, è veramente
carino).
 
Quindi è fattibile sono a runtime. Per un linguaggio tendenzialmente interpretato 
come PHP questo significa prevedere due o più modalità di corsa, una in cui 
precompilatore e ottimizzazioni sono attive, una in cui non lo sono (insieme
ovviamente a JIT e simili).
 
A meno di non voler complicare un architettura già abbastanza complessa,
anch'io sposterei la logica in componenti esterni (tipo appunto xdebug).
 
Ciao!

 anch'io sposterei la logica in componenti esterni (tipo appunto xdebug).
 
vabè per il momento vedrò di fare a meno di questa code-coverage