Il test è assolutamente essenziale per agile, soprattutto perché l'agile si basa su miglioramenti incrementali: la difficoltà è che a volte può essere difficile vedere come le modifiche attuali avranno effetto sul vecchio codice. Il modo migliore per essere sicuri di non aver infranto qualcosa è provarlo e sapere COME testarlo. In questo modo trovi subito l'errore, non in fondo alla strada quando hai dimenticato esattamente cosa hai fatto mentre stavi scrivendo il codice che ha rotto alcune vecchie funzionalità.

Il motivo per cui questo è diverso da un tipo di programmazione di tipo top-down più tradizionale è che in quell'ambiente è molto difficile da testare finché non si ha il prodotto finito b) in teoria si stanno prendendo in considerazione tutti i criteri di progettazione allo stesso tempo, e quindi è meno probabile che tu prenda una decisione di progettazione che rompa le precedenti decisioni di progettazione.

Probabilmente stai parlando di test automatici, unit test, test di integrazione, ecc. Questi sono più importanti da eseguire rispetto ai test manuali (con tester e simili) perché sono troppo lenti, quindi non è possibile testare ogni piccola modifica che rendere. Poiché agile riguarda rapide piccole iterazioni, è molto utile eseguire test che verificano la correttezza in secondi o minuti anziché in ore o giorni.

Se non hai test, come sai che il tuo codice funziona?

Modifica: l'asserzione che i test non possono dimostrare che il codice funziona non riesce a definire un termine cruciale, ovvero funziona . Cosa significa per un programma funzionare? Se si mantiene questo termine vago, allora non vi è alcun modo per dimostrare o essere sicuri che qualsiasi programma funzioni. Mai.

D'altra parte, puoi definire works come "si comporta secondo una specifica". Ora non puoi usare solo i test per mostrare che il codice funziona, ma i test stessi possono servire come una specifica eseguibile del comportamento del tuo codice. In altre parole, una suite di test ben scritta definisce cosa funziona .

Questo modo di pensare ti costringe anche a riesaminare il significato di un bug . Se il tuo codice supera tutti i test, allora non ci sono errori nel codice. Se, nonostante ciò, il sistema non si comporta come dovrebbe, il suo comportamento non viene specificato correttamente. I. e. il bug è nella specifica, definito dai test.

Questo approccio allo sviluppo del software separa le specifiche funzionali di un sistema dalla sua implementazione, che, secondo ogni libro di ingegneria del software nel mondo, è una cosa molto buona. Allo stesso tempo, questo approccio garantisce che l'implementazione corrisponda sempre alle specifiche funzionali.

No, non è "necessario"

I principi di Agile non dicono nulla direttamente sui test.

Ma è altamente consigliato

Dato l'impegno di Agile per un processo sostenibile, la consegna continua / incrementale e la qualità del software, i test automatici sono la soluzione migliore attualmente disponibile per la maggior parte dei progetti

Le eccezioni (come notato da Jörg W Mittag) includono strumenti di sviluppo provatamente corretti, sistemi di meta-programmazione che generano codice, ecc. Ma questi tipi di sistemi sono rari.

Sia Agile che XP cercano di evitare Big Design Up Front . In BDUF, i requisiti vengono raccolti, viene creata una specifica formale, la codifica quindi viene eseguita, il test quindi viene eseguito. Questo ha senso per sistemi ben definiti, missionari e vitali come attrezzature mediche, sonde spaziali, ecc.

Agile evita questo flusso perché non funziona bene per i problemi che non sono ben definiti, per esempio "qualunque cosa cambi il client chiede per questa settimana". Abbiamo ancora bisogno di una specifica formale, quindi sappiamo cosa fare e quando abbiamo finito, ma piuttosto che una sorta di documento scritto usiamo code sotto forma di test automatici.

I test unitari automatizzati sono veloci da scrivere, veloci da eseguire e molto modulari / disaccoppiati. Questo li rende un modo rapido per specificare formalmente e verificare i requisiti.