Ho fatto parte di numerosi team che provano a praticare metodologie Agile e spesso questi team sono incentrati sui test. Il test è una parte necessaria della pratica della metodologia Agile o è solo una pratica XP che è stata attaccata nel corso degli anni?

Il test è assolutamente essenziale per l'agile, principalmente perché l'agile si basa su miglioramenti incrementali: la difficoltà è che a volte può essere difficile vedere come le attuali modifiche influenzeranno il tuo vecchio codice. Il modo migliore per essere sicuri di non aver rotto qualcosa è testarlo e sapere come testarlo. In questo modo trovi immediatamente il bug, non lungo la strada quando hai dimenticato esattamente cosa hai fatto quando stavi scrivendo il codice che ha rotto alcune vecchie funzionalità.

La ragione per cui questo è diverso dalla più tradizionale programmazione top-down del tipo di progettazione è che in quell'ambiente è a) molto difficile testare fino a quando non si ottiene il prodotto finito b) in teoria si stanno prendendo in considerazione tutti i criteri di progettazione contemporaneamente e quindi è meno probabile che tu prenda una decisione di progettazione che rompe le precedenti decisioni di progettazione.

Probabilmente stai parlando di test automatici, unit test, test di integrazione ecc. Questi sono più importanti per l'agile dei test manuali (con tester e simili) perché sono troppo lenti, quindi non è possibile testare ogni piccola modifica che fai. Poiché l'agile si basa su piccole iterazioni rapide, è molto utile disporre di test per verificare la correttezza in secondi o minuti, anziché in ore o giorni.

Se non hai test, come fai a sapere se il tuo codice funziona?

Modifica: l'affermazione secondo cui i test non possono dimostrare che il codice funziona non riesce a definire un termine cruciale, vale a dire funziona . Cosa significa che un programma funziona? Se mantieni questo termine vago, non c'è modo di provare o essere sicuro che qualsiasi programma funzioni. Mai.

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

Questo modo di pensare ti costringe anche a riesaminare il significato di un bug . Se il tuo codice supera tutti i test, non ci sono bug nel codice. Se, nonostante ciò, il sistema non si comporta come dovrebbe, allora il suo comportamento non è specificato correttamente. I. e. il bug è nelle specifiche, 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, è un'ottima cosa. 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 consigliabile

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

Le eccezioni (come osservato da Jörg W Mittag) includono strumenti di sviluppo dimostrabilmente 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 vengono raccolti i requisiti, viene creata una specifica formale, quindi viene eseguita la codifica, quindi vengono eseguiti i test. Ciò ha senso per i sistemi ben definiti, mission-critical e di vita come apparecchiature mediche, sonde spaziali, ecc.

Agile evita questo flusso perché non funziona bene per problemi che non sono ben definiti, ad esempio "qualunque modifica il cliente richieda 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 il codice sotto forma di test automatizzati.

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