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