View Full Version : [Vari] - Quanti test?
Kralizek
03-04-2012, 11:22
Salve a tutti.
Dopo un periodo di sviluppo matto e disperatissimo (:doh:) ci troviamo con un'applicazione da circa 300k linee di codice senza neanche un test.
Ed ora c'é una differenza di vedute tra me ed il mio capo.
Io vorrei che lo sviluppo dei testa sia, nel tempo, quanto piú completo possibile ed eseguiti prima di ogni deploy (in stage e production).
Il mio capo dice che troppi test hanno solo l'effetto di portare lo sviluppatore a disabilitarli dopo un po'.
Capisco il suo punto di vista, ma per me avere solo una copertura parziale dei test é inutile se non dannoso per il senso di falsa sicurezza che si potrebbe avere.
Ho provato a cercare della letteratura in inglese in modo da poter analizzare insieme qualche caso di studio o almeno qualche articolo a riguardo ma non mi viene alcuna parola chiave adatta.
Ho provato con "granularity" e "coverage" ma non portano a nulla di buono.
Grazie :)
cdimauro
03-04-2012, 12:02
Non ti saprei indicare qualcosa in letteratura, perché l'idea che mi sono sviluppato sui test deriva dalla pratica.
Da questo punto di vista posso soltanto dirti che i test per me sono importantissimi per dormire abbastanza tranquillo.
Per fare un esempio, una delle ultime applicazioni su cui sto lavorando da mesi ha circa mille linee di codice Python (togliendo tutte le librerie di cui fa uso; mi riferisco al solo codice di backend di un server che espone delle API da HTTP) per circa 32KB di file, a cui aggiungiamo circa 900 linee per db + stored procedure per circa 35KB di file.
Per contro, il codice di test ha più di 3200 linee di codice, su circa 128KB di di file, per un totale di più di 360 test (che eseguiti sulla mia macchina desktop impiegano circa 2 minuti e mezzo).
Il progetto sembra di piccole dimensioni, ma avendolo scritto in Python risulta estremamente compatto.
Il tuo è ovviamente un pachiderma imparagonabile, e a maggior ragione non potrei mai stare tranquillo senza test o con una batteria di scarsissime proporzioni.
Il tuo capo ha ragione quando dice che i test diventano inutili perché vengono disabilitati, ma il punto è che NON dovrebbero assolutamente esserlo.
Il tempo speso nei test è tutto tempo guadagnato perché riduce all'osso il tempo necessario ai test manuali, ma soprattutto rende molto più solida la piattaforma, in particolare per la sua manutenzione ed evoluzione (i cambiamenti futuri diventano molto più prevedibili).
Mi rendo conto che si tratta di un'esperienza personale e, quindi, che alla fine la mia rimanga soltanto un'opinione, ma in questo campo è difficile quantificare e, men che meno, formalizzare i risultati ottenibili grazie a tecniche di extreme programming / unit testing, se non a livello puramente empirico / statistico.
300.000 righe di codice senza test sono secondo me un suicidio. In futuro, una volta messo in produzione il sistema, avrete sempre più paura di fare modifiche per il terrore di rompete qualcosa. Il progetto morira molto lentamente e fra una decina di anni sara semplicemente cestinato.
Quella del 100% di coverage è un po' un mito. Non è fondamentale e comunque non dimostra che il programma sia corretto. Cercare di arrivarci ora a cose fatte su un progetto così grande è forse anche impossibile. Penso che dovreste concetrarvi sulle parti più importanti del programma e testare almeno quelle.
Uno consiglio che ti posso dare è quello di non buttare tutto quanto in una sola Suite. Cerca di creare piccole suite di file che siano collegati tra di loro. Se fai una modifica ad una Classe che si occupa di fare il parsing di un file X è molto importante sapere subito (un paio di secpondi massimo) se hai spaccato qualcosa in quella parte di codice. Stessa cosa per le classi di test. Non c'è scritto da nessuna parte che si debba una relazione 1-a-1 tra le classi ed i test.
La mega suite con tutti i test del sistema che magari impiega 20 minuti a terminare è importante ma non si deve costringere il programmatore a lanciarla sempre prima di un commit. Perché come dice giustamente il tuo capo dopo un po' non lo farà più. Prendete in considerazione invece di mettere su un server per la continuos integration come jenkins da collegare al server svn/git che ad ogni commit lancia tutti i test e crea dei report sullo stato della build e quanti test sono passati/falliti.
Kralizek
03-04-2012, 18:27
300.000 righe di codice senza test sono secondo me un suicidio.
concordo. il mio capo una volta disse che loro sono molto "result oriented". io risposi che la parola esatta é "amatorial".
Se non mi ha licenziato quella volta (e quando gli ho detto che ha la fidanzata bona) non mi licenzia piú.
(il resto lo commento comodamente da casa ché sto ancora a lavoro)
banryu79
03-04-2012, 18:30
concordo. il mio capo una volta disse che loro sono molto "result oriented". io risposi che la parola esatta é "amatorial".
:asd: voglio un video su youtube :D
Kralizek
03-04-2012, 18:57
:asd: voglio un video su youtube :D
conosco un sito che, se usi "amatorial" come parola chiave, ti dá un sacco di risultati :oink:
Ho provato a cercare della letteratura in inglese in modo da poter analizzare insieme qualche caso di studio o almeno qualche articolo a riguardo ma non mi viene alcuna parola chiave adatta.
Ho provato con "granularity" e "coverage" ma non portano a nulla di buono.
Grazie :)
La quantita' di test piu' opportuna dovrebbe essere il miglior compromesso tra tempo speso per scrivere (e riscrivere) i test, e il tempo speso per cercare i bug che i test non fanno saltare fuori. Naturale quindi che il numero adatto sia molto dipendente dalle caratteristiche del progetto, in primis il linguaggio usato. Ad esempio con un controllo a compilazione dei tipi un certo numero di test non sono necessari, mentre d'altro canto aggiungere un singolo test in C++ ha un costo maggiore (tempo sviluppatore, tempo compilazione etc.) che non in Python.
Inoltre alcuni progetti sono piu' portati allo sviluppo di test automatici di altri: se devi sviluppare il software per far aprire e chiudere un cancello automatico, alcuni tipi di test non ti servono perche' vai a testare il modello, che puo' essere diverso dall'oggetto reale (e gli stessi test possono darti risultati diversi).
Direi quindi che la risposta e' difficilmente quantificabile ma dipende dall'esperienza, sia del linguaggio/piattaforma che del dominio in cui si lavora.
Come esperienza personale, se senti di avere bisogno di tanti test hai fatto un cattivo design :D.
Battute a parte, dovendo adottare un approccio a posteriori ha poco senso andare a cercare di coprire il piu' possibile; meglio concentrarsi sulle parti piu' pericolose. Quelle sulle quali hai il timore di mettere mano sono un buon candidato, oppure quelle su cui statisticamente devi mettere piu' spesso mano.
concordo. il mio capo una volta disse che loro sono molto "result oriented". io risposi che la parola esatta é "amatorial".
Spezzo una lancia a favore del tuo capo. La manutenibilita' del software e' solo uno degli aspetti che vanno considerati. Se scrivi software per banche conta parecchio perche' hai contratti che ti legano per anni. Se sei una startup non te ne frega niente di mettere mano al codice tra tre anni, perche' a quella data sarai gia' stata acquisita da una azienda piu' grande, oppure avrai gia' chiuso i battenti. Se sei una azienda giovane e in crescita puo' essere piu' economicamente conveniente arrivare prima degli altri col prodotto, conquistarsi una fetta di mercato, e con i guadagni andare poi a rimediare alle malefatte.
Fate come faccio io: scrivete codice senza bug! :sofico:
banryu79
05-04-2012, 11:38
Fate come faccio io: scrivete codice senza bug! :sofico:
Sì bravo, sei come il mio pasticcere: riesce a fare le ciambelle senza il buco :D
Fate come faccio io: scrivete codice senza bug! :sofico:
Piu' semplice ancora: non scrivere codice :D :P
Piu' semplice ancora: non scrivere codice :D :P
Già! Questa è una di quelle frasi zen che quando le senti la prima volta pensi "Che stronzata!" e poi un giorno invece ricevi l'illuminazione e sussurri "Ohhhh!".
Già! Questa è una di quelle frasi zen che quando le senti la prima volta pensi "Che stronzata!" e poi un giorno invece ricevi l'illuminazione e sussurri "Ohhhh!".
La produttivita' di un programmatore non si misura nel numero di linee di codice che scrive, ma in quelle che cancella :D
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.