Il linguaggio di programmazione PHP
 

Rapporto tra il codice applicativo e codice collaudo

fmigliori 3 Giu 2017 14:26
Sto sviluppando un piccolo programma e mi trovo queste statistiche:

programma 17.677 byte
unit test 56.665 byte
rapporto 320%


La domanda che vi pongo è questa: è corretto investire 3/4 del tempo nello
sviluppo dei test?
Leonardo Serni 3 Giu 2017 18:56
On Sat, 3 Jun 2017 05:26:14 -0700 (PDT), fmigliori <fmigliori@gmail.com>
wrote:

>Sto sviluppando un piccolo programma e mi trovo queste statistiche:

>programma 17.677 byte
>unit test 56.665 byte
>rapporto 320%

>La domanda che vi pongo è questa: è corretto investire 3/4 del tempo nello
sviluppo dei test?

Riassunto del riassunto: sì, ed è pure poco.

Quello che stai misurando è la DIMENSIONE del codice del programma contro
quella del test.

Se vogliamo essere filosofici - il programma descrive il modo in cui quel
che vuoi fare funziona. I test devono beccarti tutti i modi in cui invece
il programma può andare in maravalle, che sono molti di più.

Ma essendo pragmatici di quale "tempo" stai parlando? Perché non c'è mica
solo il tempo dello sviluppo.

Io ci metto due settimane a tirare su un programma complicatino fino a un
punto in cui "si vede qualcosa". Poi altri due mesi (se va bene) prima di
un rilascio speranzoso.

In questi due mesi e mezzo, diciamo che un mese e mezzo siano test.

Poi ci sono altri due mesi di debugging in cui il programma ogni tanto mi
dà gatte da pelare. E, se NON avessi i test a disposizione, quei due mesi
diventerebbero tre e mi sto trattando bene. Quindi, di quel famoso mese e
mezzo, un mese in realtà l'ho già ripreso.

Ma, e per ora non si è mai dato un caso diverso, il committente non aveva
chiare tutte le cose ganze che poteva fare con quel programma. Oppure, il
programma gli ha tolto di mezzo le tre seccature più grosse, e così, ora,
quella che era una seccatura di quart'ordine è diventata un problema - si
può modificare il programma per gestire pure quella?

In questa fase di "creeping featurism" (cit.), il rischio enorme è che la
piccola e insignificante modifica alla valvola X-Y-Z faccia esplodere una
routine usata solo a fine anno per chiudere i conti. You get my drift.

Ma con i test in posizione, appena si sposta una virgola in malo modo, il
sig. Jenkins inarca un sopracciglio e dice "Temo vi sia un errore, sir".

E tutto il tempo e il crepacuore perso a rincorrere un bug nel momento di
gran lunga peggiore possibile non c'è più.

====

>La domanda che vi pongo è questa: è corretto investire 3/4 del tempo nello
sviluppo dei test?

Puoi scegliere se metterci una settimana a fare codice, e tre settimane a
mettere su i test.

Oppure se non perder tempo a fare i test, e metterci SEI settimane a fare
il codice :-D

Io passo una significativa parte del mio tempo a MALEDIRE il tempo che ho
risparmiato nello unit testing. Un'altra parte la passo a STRAMALEDIRE il
tempo che ho risparmiato nella fase di *****isi.

Leonardo
--

A terrible beauty is born.
- W. B. Yeats, Easter 1916
Alessandro Pellizzari 3 Giu 2017 20:24
On 03/06/17 13:26, fmigliori wrote:

> Sto sviluppando un piccolo programma e mi trovo queste statistiche:
>
> programma 17.677 byte
> unit test 56.665 byte
> rapporto 320%

> La domanda che vi pongo è questa: è corretto investire 3/4 del tempo nello
sviluppo dei test?

Detto in generale si`, piu` o meno. A livello di tempo forse un po' di
meno. A livello di codice forse ne dovresti avere anche di piu`.

Il "problema" coi test e` che non c'e` un parametro assoluto che dica
quando basta o quando sia troppo.

Puoi prendere il code coverage e cercare di avvicinarti al 100% con gli
unit test, e qui entra in gioco la complessita` ciclomatica del codice,
ma se poi hai tutto coperto da unit test e non hai functional e
integration test non puoi essere sicuro che le cose interagiscano bene.

Infine dovresti avere degli acceptance test (di solito scritti con behat
o simile) per testare il livello piu` alto.

In teoria, se hai acceptance test che passano e coprono tutti i casi
d'uso potresti anche fare a meno di tutto il resto, perche` sono
dettagli di implementazione, ma e` anche vero che sono i piu` lenti e i
piu` complessi da scrivere.

Bye.
fmigliori 3 Giu 2017 22:32
Premessa
Il problema mio personale è che mi piace molto codificare il programma mentre
detesto a morte scrivere i test, o meglio non mi gratificano per niente
scriverli e aggiornarli, poi tra averli e non averli c'è una differenza enorme
e si sfondano porte aperte a iosa.
Se il test non verifica tutti i risultati possibili, errori inclusi, finisce che
diventa un falso amico, temevo (o speravo) che il metodo che avessi adottato
fosse eccessivo.

Leonardo:
> Quello che stai misurando è la DIMENSIONE del codice del programma contro
> quella del test.

Non conteggiando il tempo per i singoli processi, anche perché i test li faccio
andare di paro passo con il codice, ho questo unico indice che comunque un'idea
la può dare.

> Se vogliamo essere filosofici...
...E tutto il tempo e il crepacuore perso a rincorrere un bug nel momento di
> gran lunga peggiore possibile non c'è più.

Sono perfettamente d'accordo su tutto.

> Io passo una significativa parte del mio tempo a MALEDIRE il tempo che ho
> risparmiato nello unit testing. Un'altra parte la passo a STRAMALEDIRE il
> tempo che ho risparmiato nella fase di *****isi.

Io maledico il tempo che passo a fare test :p anche se non ne potrei fare a
meno.

Alessandro:
>Detto in generale si`, piu` o meno. A livello di tempo forse un po' di
>meno. A livello di codice forse ne dovresti avere anche di piu`.

>Il "problema" coi test e` che non c'e` un parametro assoluto che dica
>quando basta o quando sia troppo.

Questa è l'incertezza che mi infastidisce molto -non per niente ho scritto-
alla fine si trasforma
in una perdita di tempo in una direzione o nell'altra, nel senso o scrivi test
superflui o scrivi test che non coprono tutte le casistiche.

>Infine dovresti avere degli acceptance test (di solito scritti con behat
>o simile) per testare il livello piu` alto.

Sì, le colloco logicamente in una via di mezzo tra esterni e interni, anche se
sono propriamente interni.
Ho fatto solo prove proprio con behat, ma non li uso.

>In teoria, se hai acceptance test che passano e coprono tutti i casi
>d'uso potresti anche fare a meno di tutto il resto, perche` sono
>dettagli di implementazione, ma e` anche vero che sono i piu` lenti e i
>piu` complessi da scrivere.

Potrebbe essere un'idea, ma temo che rimarrei scoperto.


Grazie per le opinioni
fmassei@gmail.com 3 Giu 2017 22:48
On Saturday, June 3, 2017 at 8:26:15 AM UTC-4, fmigliori wrote:
> Sto sviluppando un piccolo programma e mi trovo queste statistiche:
>
> programma 17.677 byte
> unit test 56.665 byte
> rapporto 320%
>
>
> La domanda che vi pongo è questa: è corretto investire 3/4 del tempo nello
> sviluppo dei test?
>

Secondo me no, non solo non è corretto, è proprio una boiata.

Sono parzialmente d'accordo con Alessandro: gli unici che servono sono per
le acceptances, per cui sono praticamente i soli che scrivo.
Ci sono delle eccezioni: per ogni progetto hai al massimo uno o due algoritmi
"originali" e su quelli, se vuoi, puoi scrivere uno unit test, ma giusto
perché di solito ci lavori sopra isolati dal resto. Se trovi un bug che viene
fuori una seconda volta, o che dipende da uno sversionamento, scrivi un test
di non regressione. Altrimenti stai sempre a correggere le stesse cose.

I test non sono una perdita di tempo solo se sono utili: scrivi solo quelli!
:)

Ciao!
fmigliori 4 Giu 2017 00:42
Andrò di acceptances.

Grazie anche a te


PS
> Ci sono delle eccezioni: per ogni progetto hai al massimo uno o due algoritmi
> "originali"...

Magari
fmassei@gmail.com 4 Giu 2017 02:39
On Saturday, June 3, 2017 at 6:42:46 PM UTC-4, fmigliori wrote:
>> Ci sono delle eccezioni: per ogni progetto hai al massimo uno o due
algoritmi
>> "originali"...
>
> Magari
>

Allora lo stai facendo male :)
Nemmeno un progetto di Google Labs ne ha di più!

Ciao!
Leonardo Serni 4 Giu 2017 22:47
On Sat, 3 Jun 2017 13:48:28 -0700 (PDT), fmassei@gmail.com wrote:

>Ci sono delle eccezioni: per ogni progetto hai al massimo uno o due algoritmi
>"originali" e su quelli, se vuoi, puoi scrivere uno unit test, ma giusto
>perché di solito ci lavori sopra isolati dal resto.

Forse non ci intendiamo sul significato di "algoritmo".

Anche ad avere un algoritmo non originale, devi comunque verificare la sua
implementazione...

Leonardo
--

A terrible beauty is born.
- W. B. Yeats, Easter 1916

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio di programmazione PHP | Tutti i gruppi | it.comp.www.php | Notizie e discussioni php | Php Mobile | Servizio di consultazione news.