Agile senza test di unità

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

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

Senza i test come rete di sicurezza, introdurrai molti bug di regressione in ogni release o sarai terrorizzato dal refactoring. Entrambi avranno un strong impatto sulla tua capacità di continuare ad un ritmo sostenibile . Se non puoi sostenere il tuo passo o cambiare rotta (ridisegnare) quando richiesto, allora non hai agilità. L'agilità, dopo tutto, è l'obiettivo che ci stiamo prefiggendo.

Il manifesto agile afferma semplicemente:

Individui e interazioni su processi e strumenti

Software di lavoro su documentazione completa

Collaborazione con il cliente per la negoziazione del contratto

Risposta per cambiare rispetto a un piano

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

Quindi, tecnicamente, è possibile essere una squadra agile senza scrivere test di unità. In pratica, però, è davvero difficile vedere come un team può mantenere il software funzionante in un ambiente agile senza test per assisterli nel fare cambiamenti costanti.

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

Software di lavoro su documentazione completa.

Come si può sapere se il software funziona? Il manifesto non ha bisogno di dichiarare esplicitamente il termine test. È succinto.

I test unitari (nel contesto dell'argomento) renderanno la fase di codifica più lenta nella fase precedente, ma ne varrà la pena mentre procedi, rendendo lo sviluppo molto più veloce in avanti. Ti offre un controllo a grana fine sui test a livello di codice oltre a rendere scalabile la tua progettazione, dandoti la certezza che il tuo software funziona e può facilmente gestire la regressione; a cui renderebbe agile il tuo sviluppo.

Ha assolutamente senso. Agile non si tratta di test, come altri hanno già menzionato, ma di rispondere specificamente alla tua domanda:

No, non è affatto necessario il test dell'unità.

È possibile eseguire un processo agile con solo test di integrazione. Ad esempio, è possibile eseguire un test di integrazione automatico ogni notte e correggere i bug rilevati il giorno successivo. Potresti avere un tester manuale che esegue continuamente test di integrazione, se lo desideri. Indipendentemente dal sistema, il test dell'unità è del tutto opzionale.

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

Hai bisogno di qualche forma di test, anche se è il vecchio "beta tester clienti". Se il tuo cliente è strongmente coinvolto nel processo e non gli dispiace trovare bug, allora questo può funzionare - dato che tendono a trovare bug che nessun altro pensava fossero bug!

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

Sono felice che tu abbia riconosciuto nella tua domanda che essere agili riguarda il modo in cui si rilascia effettivamente il software invece di seguire una metodologia. The Agile Manifesto è un bel riferimento, ma non è la guida definitiva. Agile esisteva prima che lo facesse. Esistono modi per sviluppare software più "agili", ma diverse combinazioni possono essere utilizzate su vari progetti.

Se stai pubblicando un nuovo software a un ritmo accettabile per il cliente, probabilmente sei agile. Includerei anche il fatto di non avere troppi respingimenti e di lamentarsi dei cambiamenti delle funzionalità da parte degli sviluppatori. Fissare una cosa solo per rompere un altro non è l'ideale. Quando gli utenti sono diversi nelle versioni precedenti dell'aggiornamento, probabilmente non sei molto agile a prescindere dal fatto che tu collauda o meno.

Vorrei ribattere (altre risposte) che il manifesto di Agile indica chiaramente qualcosa su questo, cioè:

Continuous attention to technical excellence and good design enhances agility.

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

Organizational Agility is constrained by Technical Agility

In other words, when you are slow in making changes to your product, then it doesn’t matter how you structure your teams, your organization or what framework you adopt, you will be slow to respond to changes.

Se puoi impedire al tuo prodotto di resistere alle modifiche in un altro modo, potresti essere sulla strada giusta, ma:

I invented Extreme Programming to make the world safe for programmers. – Kent Beck

Scrum non ha alcuna pratica tecnica, ma Jeff ha detto quanto segue al riguardo:

I have never seen a hyper-productive Scrum team that didn’t use Extreme Programming development practices. – Jeff Sutherland

Quoted from this article: http://ronjeffries.com/articles/017-02ff/gathering2017/

Prevedo che i team di Scrum senza le pratiche tecniche eventualmente utilizzando le retrospettive presentino una pratica simile. Vuoi essere iper-produttivo, no?

Il modello Agile fluence , lo menziona a due stelle:

Useful techniques include continuous integration, test-driven development, pair programming, and collective ownership.

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

Quindi il consenso generale è che sì senza buone prove unitarie, codice pulito e procedure di refactoring, al momento non è possibile essere veramente agili. Questo potrebbe cambiare in futuro con l'emergere di 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.