{"id":27222,"date":"2024-04-24T14:31:45","date_gmt":"2024-04-24T12:31:45","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=27222"},"modified":"2024-05-02T17:41:50","modified_gmt":"2024-05-02T15:41:50","slug":"test-driven-development-agile","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/devops-it\/test-driven-development-agile\/","title":{"rendered":"Test Driven Development: Il primo passo verso l’Eccellenza Tecnica"},"content":{"rendered":"\n

Se c’\u00e8 una cosa che Martin Fowler e Kent Beck hanno in comune, oltre alla loro indiscutibile genialit\u00e0 nel mondo della programmazione, \u00e8 la loro passione per un approccio rivoluzionario alla scrittura del codice: il Test-Driven Development<\/strong>, o TDD, \u00e8 sicuramente una delle pratiche che li accomuna e che entrambi hanno sempre sostenuto.<\/p>\n\n\n\n

Viviamo in un mondo dove i mostri sacri della programmazione ci sussurrano all’orecchio quelle che si sono dimostrate le migliori pratiche per sviluppare software durante gli anni, ed \u00e8 una fortuna incommensurabile. <\/p>\n\n\n\n

Come ho gi\u00e0 scritto in passato su questo blog<\/a>, non si pu\u00f2 essere agili senza eccellenza tecnica: per supportare i business nell’essere veloci a rispondere, dobbiamo noi per primi essere veloci a mandare codice in produzione. <\/p>\n\n\n\n

Tra le varie pratiche che abilitano l’eccellenza tecnica c’\u00e8 sicuramente il TDD, che ha un vantaggio rispetto alle altre: \u00e8 individuale, ovvero possiamo introdurla nel nostro lavoro senza che il resto del team debba allinearsi a noi o concordare – e questo la rende la pratica pi\u00f9 semplice da introdurre per migliorare il nostro lavoro quotidiano.<\/p>\n\n\n\n

Cos\u2019\u00e8 il TDD<\/strong><\/p>\n\n\n\n

Il TDD \u00e8 una metodologia di sviluppo che si basa sul principio fondamentale di scrivere test prima di scrivere il codice di produzione, ma la defizione migliore ce la da Martin Fowler nel suo articolo<\/a> sul tema:<\/p>\n\n\n\n

\n

Test-Driven Development (TDD) is a technique for building software that guides software development by writing tests.<\/p>\nMartin Fowler<\/cite><\/blockquote>\n\n\n\n

Il TDD non ci chiede semplicemente di scrivere prima i test, anzi – quello \u00e8 solo un pezzo del puzzle. Lo scopo del TDD \u00e8 guidare le scelte che prendiamo nel software tramite la scrittura dei test, per ottenere l’obiettivo finale del TDD: “clean code that works”, ovvero “codice pulito che funziona”.<\/p>\n\n\n\n

Per ottenere questo obiettivo, il TDD ci suggerisce di seguire un ciclo di sviluppo semplice e chiaro, noto come “Red-Green-Refactor<\/strong>“: si inizia con la scrittura di un test che fallisce (rosso), seguito dall’implementazione del codice per far passare il test (verde), e infine dalla rifattorizzazione del codice per renderlo pi\u00f9 pulito e manutenibile (refactor).<\/p>\n\n\n\n

\"TDD<\/figure>\n\n\n\n

Ma cosa vuol dire tutto ci\u00f2 nella pratica? Per prima cosa, vediamo pi\u00f9 nel dettaglio il ciclo di sviluppo TDD canonico<\/a> descritto da Kent Beck, con l’aggiunta di qualche pezzo fondamentale che troppo spesso ci si dimentica:<\/p>\n\n\n\n

    \n
  1. Scrivi una lista degli scenari di test che vuoi coprire per il nuovo comportamento da aggiungere al tuo software<\/li>\n\n\n\n
  2. Prendi un elemento dalla lista e trasformalo in un test, che fallir\u00e0 perch\u00e8 quel comportamento ancora non esiste<\/li>\n\n\n\n
  3. Cambia il codice di produzione per implementare quel comportamento, in modo che il nuovo test diventi verde (e i precedenti lo rimangano)\n