Che differenza c’è tra unit test e acceptance test? In quali occasioni è opportuno scrivere uno unit test e quando invece è meglio scrivere un acceptance test?
Queste sono domande tipiche e più che legittime quando un team inizia a muovere i primi passi nel mondo del testing automatico. Personalmente scrivo il mio codice attraverso il TDD ormai da parecchio tempo, ma mi è capitato di lavorare con team che scrivono test automatici solo dopo aver scritto il codice applicativo corrispondente. Non solo: uno sviluppatore o un team che si interessano al TDD tipicamente passano qualche tempo praticando test-after, prima di iniziare a muoversi test-driven. È un’evoluzione naturale quindi ed è un po’ come imparare a camminare prima di iniziare a correre. Spero che sia evidente che la mia netta preferenza va verso un approccio test-driven.
Detto ciò, le informazioni che seguono costituiscono un approccio al testing pragmatico e volutamente non formalizzato: hanno l’obiettivo di aiutarvi nelle vostre attività quotidiane. Di conseguenza, le definizioni e i suggerimenti qui riportati non vogliono essere necessariamente a prova di bomba da un punto di vista formale, ma spero che possano essere efficaci nel vostro contesto professionale.
Questa prima parte è concentrata sugli unit test.
Al ritorno dalle vacanze d’agosto siamo stati accolti da una notizia che farà senz’altro discutere. 
Ispirati forse dal successo del 
Hai idee per un articolo? 
Commenti recenti