Che cosa sono TDD e ATDD?

In questo articolo, evidenziamo le somiglianze e le differenze tra due popolari metodi di testing comunemente conosciuti come TDD e ATDD.

TDD sta per test-driven development, mentre ATDD sta per acceptance test-driven development. Capire come funzionano questi due approcci di test è fondamentale per i professionisti del testing e questo post sarà un primer per iniziare la scoperta di entrambi. Capirete TDD vs ATDD.

Che cos’è il Test-Driven Development (TDD)?

TDD è un sistema di sviluppo del software che segue i principi dell’Extreme Programming (XP), tuttavia nel tempo è diventato una tecnica indipendente di sviluppo del software.

In TDD, i test delle unità vengono eseguiti direttamente sul codice sorgente.

In primo luogo, il tester scrive un caso di test automatico che definisce la funzione desiderata che il sistema dovrebbe idealmente eseguire, ma progetta appositamente il caso di test in modo tale che non possa essere soddisfatto dal sistema nel suo stato attuale.

In secondo luogo, lo sviluppatore prende nota dei motivi per cui il sistema non ha soddisfatto il test e scrive il codice necessario per rifattorizzare il sistema e permettergli di superarlo nel secondo tentativo. Questo processo è riassunto nel grafico qui sotto.

Il processo TDD continua in questo modo, zigzagando tra fallimento e successo, così che ogni iterazione spinge il sistema ai suoi limiti e poi lo aiuta a superarli attraverso il feedback che viene generato.

Il TDD è un esperimento di fallimento volontario e ci vuole un certo coraggio per avvolgere la testa intorno a questa tecnica contro-intuitiva. Tuttavia, una volta fatto, sarete ricompensati con un metodo semplice ma altamente efficace per combattere la paura del fallimento durante i test, migliorando il lavoro che fate.

Che cos’è l’Acceptance Test-Driven Development (ATDD)?

ATDD è un metodo collaborativo di test che costringe tutte le persone coinvolte nella creazione di un nuovo software (es.Ad esempio, tester, sviluppatori e utenti) a definire come una squadra i criteri di accettazione che il sistema deve soddisfare nelle prime fasi di sviluppo.

Lo scopo di questa fase è quello di garantire che tutti questi attori siano d’accordo sugli obiettivi principali del progetto, soprattutto in termini di funzionalità che l’utente finale può aspettarsi. Durante questa fase dell’ATDD, tecniche come user personas e user stories possono essere molto utili.

Quando i test di accettazione vengono finalmente eseguiti sul sistema, i fallimenti vengono annotati e gli sviluppatori rifattorizzano i componenti difettosi scrivendo il codice necessario per soddisfare i criteri di accettazione al prossimo tentativo.

Questo processo viene eseguito iterativamente, di solito alla fine di ogni sprint, finché il prodotto finale è pronto per il deployment. Il grafico qui sotto lo spiega.

ATDD fornisce al team una visione più chiara di come funzionerà il prodotto finale, permettendo a tutti di rimanere concentrati sugli obiettivi a lungo termine piuttosto che perdersi in singole righe di codice.

In sintesi

Ora hai una buona comprensione delle differenze di base tra TDD e ATDD. Questi due metodi di test sono strettamente correlati, tuttavia ATDD include anche il test di accettazione nel processo e dà più importanza alla collaborazione del team rispetto a TDD.

Entrambi gli approcci si adattano bene ai principi agili poiché entrambi incoraggiano la raccolta di feedback per costruire sui vostri errori precedenti. Mentre rifattorizzi continuamente il sistema e affronti i problemi che hai affrontato nel tentativo precedente, questi metodi ti aiutano a sviluppare un prodotto finale di maggior valore in modo incrementale.

Unisciti agli oltre 60.000 abbonati

per gli ultimi blog, aggiornamenti del settore e consigli esclusivi.

*La tua email è sicura con noi, odiamo anche lo spam