Monday, September 10, 2007
Ruminazioni sul testing /0
Il mio cruccio attuale e` il diventare test infected. Metto subito le mani avanti pero`. In quanto convinto murphysta sono scettico anche riguardo a questa metodologia. Non credo nella sua applicaziona ultraortodossa, forse, non lo nego, anche perche` mi tange di rado. Ma, piu` del resto, sono cosciente che la qualita` del testing che eseguo abitualmente, sia per dovere sia per diletto, non mi soddisfa affatto. Insoddisfacente sia per estensione sia per profondita`. I motivi sono i soliti, e sto trovando anche delle difficolta` vhe ritengo oggettive. Per esempio, nel caso di transcode: come eseguire test soddisfacenti su componenti multithreaded (src/framebuffer.c) senza scrivere un testcase che e` di complessita` paragonabile a quello dell'applicazione? E` l'approccio giusto? Se si, come procedere? Se no, come non farsi delle domande? (riguardo ad una metodologia che ha dei benefici, ma che rischia di lasciare scoperte le parti piu` critiche del software, coprendo invece a tappeto quelle meno critiche). Non sto discutendo la metodologia. Non ancora almeno. Sto discutendo pesantemente la mia appicazione della stessa, perche` e` troppo, troppo scarsa. Ed e` ora di porvi rimedio facendo qualche serio sforzo in tal senso; da qui, tra le altre cose, questa (spero) serie di post sull'argomento.
Labels: idee, programmazione
// posted by Ikitt @ Monday, September 10, 2007 
Comments:
<< Home
il mantra del Vero Programmatore Test Driven dice che se una cosa è difficile da testare allora è mal progettata.
Perché è difficile testare framebuffer.c ?
Il codice è isolato dagli altri moduli, o si potrebbe renderlo più indipendente dal resto?
É possibile ridurre le funzionalità che accedono allo stato condiviso/globale in modo da verificarle singolarmente?
Un test che ne verifichi le funzionalità sarebbe complesso, ma sarebbe forse riutilizzabile per verificare altre funzionalità? Se no, perché?
Come tutti i dogmi va preso con le molle, ma _io_ sono stato infettato dal virus del TDD quando ho interiorizzato questa cosa.
A proposito, come effettui i test, usi una libreria, script di shell + miniprogrammi ad hoc, un framework esistente ?
Perché è difficile testare framebuffer.c ?
Il codice è isolato dagli altri moduli, o si potrebbe renderlo più indipendente dal resto?
É possibile ridurre le funzionalità che accedono allo stato condiviso/globale in modo da verificarle singolarmente?
Un test che ne verifichi le funzionalità sarebbe complesso, ma sarebbe forse riutilizzabile per verificare altre funzionalità? Se no, perché?
Come tutti i dogmi va preso con le molle, ma _io_ sono stato infettato dal virus del TDD quando ho interiorizzato questa cosa.
A proposito, come effettui i test, usi una libreria, script di shell + miniprogrammi ad hoc, un framework esistente ?
# posted by 
: 8:22 PM
: 8:22 PM
riffraff: speravo in un tuo intervento ;)
Sul mantra: probabilmente e` cosi`, sebbene scommetterei sul fatto che il codice e` meno progettato peggio oggi che in passato.
E` difficile testare framebuffer.c perche` gli errori che temo (hangup, deadlock, livelock) si possono ricreare solo in ambiente multithreaded, e sono in serio imbarazzo a tirar su dei testcase che ricreano le sequenze di schedulazione corrette e non corrette.
Forse, molto probabile, sto sbagliando qualcosa nell'approccio, oppure il test driven development mostra la corda proprio in casi come questi? (non sto insinuando, perche` io voglio trovare un metodo soddisfacente per ridurre tutte quelle regressioni di cui soffriamo, sto chiedendo).
Su come ridurre le funzionalita`: ci sto lavorando, gradualmente ci si arrivera` (ma prevalentemente navigando a vista, vista la situazione), ma devo ancora schiarirmi le idee.
Idem sulla riutilizzabilita`, e` una domanda su cui dovrei riflettere.
Come effettuiamo i (troppo pochi) test:
miniprogrammi ad hoc e script di shell.
Sarei intenzionato a introdurre una libreria tipo check o cutest (ma ormai dopo la prossima release) se convinco gli altri.
Approfitto per chiedere: MOLTO graditi libri, paper, articoli, qualunque cosa con suggerimenti su come impostare e far crescere la cosa. ITA/ENG indifferente, gratis/pagamento idem (soldi spesi bene IMHO). Noto con un certo imbarazzo che i documenti sul testing che ho visto
fanno esempi sul banale andante.
Sul mantra: probabilmente e` cosi`, sebbene scommetterei sul fatto che il codice e` meno progettato peggio oggi che in passato.
E` difficile testare framebuffer.c perche` gli errori che temo (hangup, deadlock, livelock) si possono ricreare solo in ambiente multithreaded, e sono in serio imbarazzo a tirar su dei testcase che ricreano le sequenze di schedulazione corrette e non corrette.
Forse, molto probabile, sto sbagliando qualcosa nell'approccio, oppure il test driven development mostra la corda proprio in casi come questi? (non sto insinuando, perche` io voglio trovare un metodo soddisfacente per ridurre tutte quelle regressioni di cui soffriamo, sto chiedendo).
Su come ridurre le funzionalita`: ci sto lavorando, gradualmente ci si arrivera` (ma prevalentemente navigando a vista, vista la situazione), ma devo ancora schiarirmi le idee.
Idem sulla riutilizzabilita`, e` una domanda su cui dovrei riflettere.
Come effettuiamo i (troppo pochi) test:
miniprogrammi ad hoc e script di shell.
Sarei intenzionato a introdurre una libreria tipo check o cutest (ma ormai dopo la prossima release) se convinco gli altri.
Approfitto per chiedere: MOLTO graditi libri, paper, articoli, qualunque cosa con suggerimenti su come impostare e far crescere la cosa. ITA/ENG indifferente, gratis/pagamento idem (soldi spesi bene IMHO). Noto con un certo imbarazzo che i documenti sul testing che ho visto
fanno esempi sul banale andante.
eh, mi sopravvaluti :)
Temo che sia vero che situazioni come queste siano le più complicate da testare, almeno da quel che vedo in giro.
Non avendo mai fatto TDD in C non ho praticamente nessuna lettura da suggerirti.
Un libro carino che lessi sul TDD è "unit testing in java with Junit" dei pragprog (o il gemello "in C# with nunit").
E' abbastanza generico e cough..si trova in pdf..cough ma temo dia consigli o troppo generali ("test boundary conditions") o troppo specifici per la piattaforma e per i linguaggi OO ("use mock objects").
Forse il posto migliore dove trovare consigli su letture ed approcci è la mailing list di Extreme Programming italia (http://groups.yahoo.com/group/extremeprogramming-it/)
Post a Comment
Temo che sia vero che situazioni come queste siano le più complicate da testare, almeno da quel che vedo in giro.
Non avendo mai fatto TDD in C non ho praticamente nessuna lettura da suggerirti.
Un libro carino che lessi sul TDD è "unit testing in java with Junit" dei pragprog (o il gemello "in C# with nunit").
E' abbastanza generico e cough..si trova in pdf..cough ma temo dia consigli o troppo generali ("test boundary conditions") o troppo specifici per la piattaforma e per i linguaggi OO ("use mock objects").
Forse il posto migliore dove trovare consigli su letture ed approcci è la mailing list di Extreme Programming italia (http://groups.yahoo.com/group/extremeprogramming-it/)
Subscribe to Post Comments [Atom]
<< Home
Subscribe to Posts [Atom]