| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

ReportMeet20070530

Page history last edited by PBworks 16 years, 10 months ago

Meet, 30 maggio 2007. Tema: Test Automation

 

Dopo quasi un anno e mezzo di attività del Milano eXtreme Programming User Group siamo tornati ospiti di sourcesense e lo abbiamo fatto in una serata durante la quale abbiamo affrontato il tema dell'automazione dei test. La prima parte dell'incontro è stata dedicata ad una presentazione di Gabriele Lana che è stata gentilmente filmata, dopo una piccola pausa si è aperta una tavola rotonda fra i presenti per approfondire alcuni argomenti fra i quali

 

  • Come "vendere" il costo dei test automatici? Risposte: il test (sopratutto quello unitario) dovrebbe essere parte dello sviluppo del codice e come tale non può essere scorporato e contanto come una pratica a parte (sarebbe come chiedere quanto costerebbe il prodotto se eliminassimo l'uso di variabili locali?). Come viene detto nella presentazione, i test si pagano da soli dando prevedibilità al processo di sviluppo e stabilità ai costi di modifica, risparmiare sui test significa risparmiare sulla qualità e ottenere un'aumento di velocità nel breve periodo, ma significa anche ritardare inesorabilmente ed eventualmente condannare a morte il progetto nel medio e nel lungo periodo
  • Vi è mai capitato di dover rivedere l'architettura del vostro codice a causa dei test? Risposte: sempre! E' il fondamento del Test Driven Development :-)
  • Chi testa il test? Risposte: il codice dell'applicazione che rappresenta il duale del codice del test, infatti una tecnica per fare refactoring del codice di test è modificare il codice di produzione per far fallire un paio di test unitari, rifattorizzare il codice di test controllando che siano sempre quei test a fallire, annullare le modifiche fatte al codice di produzione e verificare che tutti i test passino. Non dovrebbe esserci grande necessità di testare il codice dei test unitari in quanto dovrebbe essere estremamente semplice e chiaro (in modo da fungere da documentazione del codice testato), nel caso non lo fosse, o basta un po' di refactoring oppure possiamo sempre estrarre il codice dai test e metterlo in una libreria che andremo a testare :-)

 

Alla serata, oltre allo zoccolo duro degli abituè, hanno partecipato un po' di volti nuovi e questo è molto incoraggiante

 

La serata si è conclusa come si era conclusa quella di un anno e mezzo fa, ovvero da un'ottimo kebabbaro

Comments (0)

You don't have permission to comment on this page.