Cos'è lo sviluppo guidato dai test?

Usa la metodologia TDD e la suite di test fornita per risolvere gli esercizi

Lo sviluppo guidato dai test (a volte chiamato anche sviluppo test-first o progettazione guidata dai test) è la pratica di scrivere i test unitari prima, prima di scrivere anche una sola riga di codice di implementazione.

Su Exercism, i test sono i requisiti!

Tutti gli esercizi di pratica su cui lavori (quelli che non ti insegnano un nuovo concetto) hanno delle istruzioni che descrivono in termini generali cosa devi fare. Per scelta, queste istruzioni non tengono conto dei dettagli di implementazione specifici di un linguaggio di programmazione, perché sono condivise da tutti gli oltre 70 track di linguaggi di Exercism. Alcuni track aggiungono dettagli più specifici, ma non tutti lo fanno.

Quando inizi a lavorare su un esercizio di pratica, leggi le istruzioni con attenzione. Ti daranno una panoramica generale di come procedere per implementare una soluzione. Ma dovrai leggere i test per capire i requisiti completi e precisi:

  • Il risultato deve essere un particolare tipo di struttura dati?
  • Il risultato deve essere ordinato in un certo modo?
  • Come ci si aspetta che gestisci le eccezioni? E così via.

Hai risolto un esercizio quando tutti i test forniti vengono eseguiti e superati. In altre parole, la soluzione non è solo un'interpretazione delle istruzioni che «sembra giusta»: è un programma che soddisfa i test forniti. I test rappresentano i requisiti completi dell'esercizio.

Come applica Exercism il TDD?

Abbiamo già fatto il lavoro di scrivere una suite di test unitari per te. L'obiettivo è scrivere una soluzione che contenga appena il codice necessario per far passare tutti quei test unitari.

Tieni presente questo: l'approccio TDD ti aiuterà ad arrivare alla soluzione, ma non devi per forza fermarti lì. Se vuoi estendere la soluzione oltre i requisiti, sei libero di farlo. Se scegli di lavorare con un mentore (e ti incoraggiamo a farlo una volta che i test passano), potrà aiutarti a riorganizzare e rifinire l'implementazione iniziale, o persino proporti nuovi test unitari.

Lavorare nell'editor online

Quando lavori nell'editor di codice sul sito di Exercism, puoi leggere i test ma non puoi modificarli. Tutti i test vengono eseguiti ogni volta che li esegui, indipendentemente da eventuali meccanismi di «skip» indicati nel file di test.

Quando ci sono più test che falliscono, all'inizio il sito mostra solo i risultati del primo fallimento. Puoi cliccare anche sugli altri fallimenti per espanderli! A volte il primo risultato potrebbe non essere il più informativo.

Non scoraggiarti se ci sono molti test che falliscono. Concentrati sul farli passare uno alla volta.

Lavorare in locale

Molti track usano test «saltati» nei loro file di test. All'inizio solo il primo test è «attivo» e gli altri sono inattivi (come questo avvenga varia da track a track). Quando esegui la suite di test nel tuo ambiente, viene eseguito solo il primo test. Lo facciamo per incoraggiarti a seguire questo flusso di lavoro:

  1. Prima di aggiungere nuovo codice, esegui la suite di test: dovresti vedere un test che fallisce.
  2. Aggiungi quel tanto che basta di codice per far passare il test.
  3. Esegui la suite di test.
  4. Se il test fallisce ancora, ripeti il passo 2.
  5. Una volta che il test passa, riorganizza il codice come preferisci, assicurandoti che tutti i test attivi continuino a passare. La riorganizzazione può includere:
    • rimuovere il codice duplicato,
    • dividere le funzioni lunghe in funzioni più piccole,
    • aggiungere commenti, ecc.
  6. «Riattiva» il test successivo e riparti dal passo 1.

Ripeti questi passaggi finché non hai riattivato tutti i test. Una volta che tutti i test passano, complimenti, hai risolto l'esercizio!

Come esattamente i test vengano «riattivati» (o attivati) dipende dal track. Per alcuni track può voler dire commentare o rimuovere un'annotazione. Per altri, può voler dire cambiare un attributo da true a false. Prenditi il tempo di leggere la documentazione del tuo track; spiegherà questi dettagli.

Per i track che non saltano i test, applicare questo flusso di lavoro può essere semplice come trasformare i test in commenti e riattivarli uno alla volta.

Perché lo sviluppo guidato dai test

Anche se può sembrare «mettere il carro davanti ai buoi», ci sono diverse buone ragioni per scrivere i test unitari prima del codice di implementazione.

  1. Progettazione. Ti costringe a pensare prima all'interfaccia del programma (come espone le sue funzionalità al mondo), invece di buttarti subito su come implementare il codice. Avere un'interfaccia ben progettata (e testabile!) è spesso più importante di avere un'implementazione efficiente.

  2. Disciplina. Scrivere i test è spesso visto come una seccatura o come qualcosa a cui pensare solo dopo; scrivere i test per primi garantisce che alla fine avrai scritto abbastanza test unitari da coprire la maggior parte, o tutte, le funzionalità del codice (invece di non arrivare mai a farlo).

  3. Meno lavoro. Se applichi un ciclo stretto in cui scrivi un test, poi scrivi il codice per implementarlo, poi scrivi il test successivo, il codice finisce per crescere in modo organico. Questo spesso (anche se non sempre) porta a meno sforzo sprecato: finisci per scrivere tutto il codice che ti serve e nessuno di quello che non ti serve.

Per approfondire