Agile senza test unitari

Ha senso parlare di "sviluppo agile" o affermare che si sta applicando una "metodologia agile" se la base di codice su cui si sta lavorando ha una copertura unitaria dello 0%? (E tu, come squadra, non stai facendo nulla al riguardo).

Per chiarire: per me non ha senso. Nella mia esperienza personale ho scoperto che i test unitari sono l'unico strumento che ti consente di essere veramente "agile" (ovvero rispondere ai cambiamenti, migliorare il tuo design, condividere le conoscenze, ecc ...) e TDD è l'unica pratica che ti porta lì .

Forse ci sono altri modi, ma non riesco ancora a vedere come possano funzionare.

Per essere pedanti, nulla nel Manifesto Agile o nella Guida Scrum fa alcun riferimento a pratiche tecniche, come test unitari o TDD. Quindi, sì, in teoria potresti consegnare presto e spesso concentrandoti sulla collaborazione e sul valore senza di loro e definendoti Agile, potresti addirittura avere agilità .

In pratica, tuttavia, è quasi impossibile fornire costantemente valore ( in produzione ) ogni poche settimane senza una buona suite di test. Ciò include test di integrazione e test unitari. I test unitari vanno solo così lontano. C'è una ragione per cui è una piramide e non un rettangolo dopo tutto.

Senza i test come rete di sicurezza, introdurrai molti bug di regressione in ogni versione o sarai terrorizzato dal refactoring. Entrambi influenzeranno notevolmente la tua capacità di continuare a un ritmo sostenibile . Se non riesci a mantenere il ritmo o cambiare rotta (riprogettazione) quando richiesto, non hai agilità. L'agilità, dopo tutto, è l'obiettivo per cui ci stiamo impegnando.

Il manifesto agile afferma semplicemente:

Individui e interazioni su processi e strumenti

Software funzionante su documentazione completa

Collaborazione con i clienti sulla negoziazione del contratto

Rispondere al cambiamento seguendo un piano

Nessuna menzione di test unitari lì. Anche i 12 principi non menzionano i test.

Quindi, tecnicamente, è possibile essere una squadra agile senza scrivere unit test. In pratica, però, è davvero difficile capire come un team possa mantenere il software funzionante in un ambiente agile senza test per aiutarlo a fare cambiamenti costanti.

Anche se non ci sono parole dirette sul test unitario o TDD o qualsiasi tipo di test nel manifesto agile come altri hanno risposto qui, credo che un buon Scrum Master o Developer sarebbe in grado di discernere una delle affermazioni nel manifesto.

Software funzionante  su documentazione completa.

Come si potrebbe sapere se il software funziona? Non è necessario che il manifesto dichiari esplicitamente il termine test. È succinto.

I test unitari (nel contesto dell'argomento) rallenteranno la fase di programmazione nella fase precedente, ma ne varrà la pena man mano che avanzi, rendendo lo sviluppo molto più veloce in avanti. Ti offre un controllo accurato sui test a livello di codice, oltre a rendere scalabile il tuo design, dandoti la sicurezza che il tuo software funzioni e può facilmente gestire la regressione; a cui renderebbe agile il tuo sviluppo.

Ha assolutamente senso. Agile non riguarda i test, come altri hanno già detto, ma per rispondere in modo specifico alla tua domanda:

No, non hai bisogno di test unitari.

È possibile eseguire un processo agile solo con i test di integrazione. Ad esempio, è possibile eseguire un test di integrazione automatizzato ogni notte e correggere i bug rilevati il ​​giorno successivo. Se lo desideri, potresti avere un tester manuale che esegue continuamente test di integrazione. Indipendentemente dal sistema, il test unitario è del tutto facoltativo.

Potresti scoprire che i test unitari ti aiutano a sviluppare, e abbastanza equo, ma ci sono molte cose che possono aiutare lo sviluppo che potresti non avere.

Tuttavia, hai bisogno di una qualche forma di test, anche se si tratta dei vecchi "beta tester per i clienti". Se il tuo cliente è fortemente coinvolto nel processo e non si preoccupa di trovare bug, allora può funzionare, poiché tendono a trovare bug che nessun altro ha mai pensato che fossero bug!

Non è richiesto Il test è ottimo quando hai persone che sanno davvero come usarlo. Quando non lo fai, non solo non è necessario, diventa una responsabilità. Direi che ci sono molti programmatori che non sono molto abili.

Sono contento che tu abbia riconosciuto nella tua domanda che essere agili riguarda il modo in cui rilasci effettivamente il software invece di seguire una metodologia. Il Manifesto Agile è un bel riferimento, ma non è la guida definitiva. Agile esisteva prima di lui. Esistono modi per sviluppare software più "agili", ma è possibile utilizzare combinazioni diverse su vari progetti.

Se rilasci nuovi software a un ritmo accettabile per il cliente, probabilmente sei agile. Includerei anche non avere troppi push-back e lamentarsi delle modifiche delle funzionalità da parte degli sviluppatori. Neanche riparare una cosa per romperne un'altra è l'ideale. Quando sei un utente con diverse versioni in fase di aggiornamento, probabilmente non sei molto agile sia che tu provi o meno.

Vorrei contrastare la tesi (altre risposte) che il manifesto Agile afferma chiaramente qualcosa al riguardo, vale a dire:

L'attenzione costante all'eccellenza tecnica e al buon design aumentano l'agilità.

Mi piace molto la definizione LeSS di eccellenza tecnica e include unit test e TDD. Ora puoi sostenere che potresti non aver bisogno di unit test o TDD per raggiungere questo obiettivo, ma è il modo più comune e probabilmente consigliato.

L'agilità organizzativa è limitata dall'agilità tecnica

In altre parole, quando sei lento ad apportare modifiche al tuo prodotto, non importa come strutturi i tuoi team, la tua organizzazione o quale struttura adotti, sarai lento a rispondere alle modifiche.

Se riesci a impedire al tuo prodotto di resistere al cambiamento in un altro modo, potresti essere sulla strada giusta, ma:

Ho inventato la programmazione estrema per rendere il mondo sicuro per i programmatori. - Kent Beck

Scrum non ha alcuna pratica tecnica, ma Jeff ha dichiarato quanto segue:

Non ho mai visto un team Scrum iper-produttivo che non ha utilizzato le pratiche di sviluppo di Extreme Programming. - Jeff Sutherland

Citato da questo articolo: http://ronjeffries.com/articles/017-02ff/gathering2017/

Mi aspetterei che i team Scrum senza pratiche tecniche alla fine, usando le retrospettive, escogitino una pratica simile. Vuoi essere anche iper-produttivo, no?

Il modello di fluenza Agile lo menziona a due stelle:

Le tecniche utili includono l'integrazione continua, lo sviluppo guidato dai test , la programmazione delle coppie e la proprietà collettiva.

Se scegli come target solo il primo livello di fluidità Agile, potresti saltare la pratica, ma qualsiasi prodotto più grande e più lungo dovrebbe almeno tentare di raggiungere un livello a due stelle.

Quindi il consenso generale è che sì, senza buone prove di unità, codice pulito e pratiche di refactoring, attualmente non è possibile essere veramente agili. Questo potrebbe cambiare in futuro quando emergeranno nuove pratiche tecniche.

Quale pensi che sarebbe la risposta se chiedessimo ad alcuni firmatari del manifesto come Robert C. Martin, Martin Fowler o Kent Beck? Forse diranno che dipende, ma generalmente è qualcosa che dovresti fare.