Vale la pena provare unit unit o lo sviluppo test-driven?

Il mio team al lavoro si sta trasferendo a Scrum e altri team stanno iniziando a fare lo sviluppo guidato dai test utilizzando test unitari e test di accettazione dell'utente. Mi piacciono gli UAT, ma non sono venduto su unit test per lo sviluppo test-driven o sviluppo test-driven in generale.

Sembra che scrivere test sia un lavoro extra, dà alle persone una stampella quando scrivono il vero codice e potrebbero non essere efficaci molto spesso.

Capisco come funzionano i test unitari e come scriverli, ma qualcuno può dire che è davvero una buona idea e che vale la pena e il tempo?

Inoltre, c'è qualcosa che rende TDD particolarmente buono per Scrum?

Risposta breve: assolutamente positivo.

Risposta lunga: I test unitari sono una delle pratiche più importanti che cerco di influenzare sul mio posto di lavoro (banca di grandi dimensioni, trading FX). Sì, sono un lavoro extra, ma è un lavoro che ripaga ancora e ancora. I test unitari automatizzati non solo ti aiutano ad eseguire effettivamente il codice che stai scrivendo e, naturalmente, verificano le tue aspettative, ma fungono anche da una sorta di cane da guardia per i futuri cambiamenti che tu o qualcun altro potresti fare. La rottura del test si verificherà quando qualcuno modifica il codice in modi indesiderati. Penso che il valore relativo dei test unitari diminuisca in correlazione con il livello di cambiamento e crescita previsti in una base di codice, ma la verifica iniziale di ciò che il codice rende utile anche quando la modifica prevista è bassa. Il valore del test unitario dipende anche dal costo dei difetti. Se il costo (dove il costo è perdita di tempo / denaro / reputazione / sforzo futuro) di un difetto è zero, anche il valore relativo di un test è zero; tuttavia questo non è quasi mai il caso in un ambiente commerciale.

In genere non assumiamo più persone che non creano abitualmente test unitari come parte del loro lavoro - è solo qualcosa che ci aspettiamo, come presentarci ogni giorno. Non ho visto una pura analisi costi-benefici di avere unit test (qualcuno non ha dubbi di indicarmene uno), tuttavia posso dire per esperienza che in un ambiente commerciale vale la pena provare che il codice funziona in un grande sistema importante . Mi permette anche di dormire meglio la notte sapendo che il codice che ho scritto funziona in modo dimostrabile (a un certo livello), e se cambia qualcuno verrà avvisato di eventuali effetti collaterali imprevisti da una build rotta.

Lo sviluppo guidato da test, nella mia mente non è un approccio test. In realtà è un approccio / pratica di progettazione con l'output come sistema di lavoro e una serie di test unitari. Sono meno religioso riguardo a questa pratica in quanto è un'abilità che è abbastanza difficile da sviluppare e perfezionare. Personalmente, se sto costruendo un sistema e non ho una chiara idea di come funzionerà, impiegherò TDD per aiutarmi a trovare la mia strada nel buio. Tuttavia, se sto applicando un modello / soluzione esistente, in genere non lo farò.

In assenza di prove matematiche per te che abbia senso scrivere test unitari, ti incoraggio a provarlo per un lungo periodo e a sperimentare i benefici da solo.

Gli errori rilevati in precedenza sono meno costosi da correggere rispetto agli errori rilevati in seguito. TDD ti aiuta a verificare la correttezza del tuo sistema. Investi un po 'più in anticipo, ma lo riprendi più tardi. Il grafico è un po 'esagerato, ma mostra bene l'idea.

Fonte immagine

Vale la pena testare l'unità o lo sviluppo guidato dai test?

Sì lo fa . Zio Bob (Robert C Martin) raccontato in una presentazione;

Per uno sviluppatore dimostrare che il suo codice funziona meglio per scrivere un test e superarlo piuttosto che urlare, cantare o ballare al riguardo.

E poiché non si eliminerà il test, purché il test sia un passaggio, si è sicuri che la funzionalità funzioni - i problemi di regressione sono risolti.

Ci sono molte cose scritte su di esso,

1. Sei responsabile di far funzionare quella funzione. Scrivi un test. Fallo e basta.
2. Quando sostituire i test unitari con il test di integrazione

SCRUM, Test unitari e TDD sono correlati?

In breve, quando sarai un maestro Unit testing, sarai vicino a TDD. SCRUM non ha nulla a che fare con questo, ma come si dice, le cose grandi si mescolano bene, queste tecniche di sviluppo di un software si sommano in uno stack eccellente , se non l'hai ancora provato, provalo.

C'è qualcosa che rende TDD particolarmente buono per SCRUM?

Come ho detto sopra , formano una buona combinazione ; Se aggiungi alcuni test di automazione ad esso, allora è più speciale .

Sembra che scrivere test sia un lavoro extra, dà alle persone una stampella quando scrivono il vero codice e potrebbero non essere efficaci molto spesso.

Il test unitario ha valore come stampella. Supporta i tuoi sforzi di sviluppo, consentendoti di modificare l'implementazione senza temere che l'applicazione smetta di funzionare come richiesto. I test unitari sono anche molto più di una stampella, in quanto offrono uno strumento con il quale è possibile verificare che l'implementazione soddisfi i requisiti.

Tutti i test, siano essi test unitari, test di collaudo, test di integrazione e così via, sono efficaci solo quanto le persone che li utilizzano. Se ti avvicini al tuo lavoro in modo sciatto, i tuoi test saranno sciatti e la tua implementazione avrà problemi. Allora perché preoccuparsi? Ti preoccupi dei test perché devi dimostrare a te stesso e ai tuoi clienti che il tuo software funziona e che non ha problemi che potrebbero impedire l'utilizzo del software. Sì, i test sono sicuramente un lavoro extra, ma il modo in cui eseguirai i test determinerà quanta fatica dovrai fare per correggere i bug dopo il rilascio e quanta fatica il tuo codice richiederà per cambiare e mantenere.

Capisco come funzionano i test unitari e come scriverli, ma qualcuno può dire che è davvero una buona idea e che vale la pena e il tempo?

TDD, e in realtà qualsiasi metodo che richiede di scrivere test prima di scrivere il codice, utilizza l'approccio che si impegna in anticipo come acconto sul debito tecnico futuro. Mentre lavori attraverso il progetto, tutto ciò che si perde o non viene implementato bene comporta un maggiore debito tecnico sotto forma di una maggiore difficoltà di manutenzione, che influisce direttamente sui costi futuri e sui requisiti di risorse. I test anticipati assicurano che non solo tu abbia fatto uno sforzo per affrontare il debito tecnico futuro, ma ti assicurano anche di codificare i tuoi requisiti in modo tale che possano essere verificati semplicemente eseguendo il tuo codice. Il test prima ti dà anche l'opportunità di convalidare la tua comprensione del dominio del problema prima di impegnarti a risolvere il problema nel codice e convalida i tuoi sforzi di implementazione.

Dipende davvero dal tentativo di massimizzare il valore commerciale del tuo codice. Il codice ampiamente non testato e difficile da mantenere è generalmente economico e veloce da creare e molto costoso da mantenere per tutta la durata del prodotto dopo il rilascio. Il codice che è stato testato accuratamente a livello di unità è generalmente più costoso da creare, ma costa relativamente poco da mantenere per tutta la durata del prodotto dopo il rilascio.

Inoltre, c'è qualcosa che rende TDD particolarmente buono per SCRUM?

TDD non è specificamente buono per una particolare metodologia. È semplicemente uno strumento. Una pratica che puoi integrare nei tuoi processi di sviluppo al fine di aiutarti a raggiungere i tuoi risultati specifici. Quindi, per rispondere alla tua domanda, TDD è complementare al tuo metodo, che sia SCRUM o qualsiasi altro approccio.

La gente pensa che sia uno sforzo extra perché è un'attività iniziale. Quello che perdi nel tempo ora lo ritorni più tardi.

Le mie ragioni per i test unitari includono anche:

Ti dà un obiettivo: non puoi scrivere un test se non sai cosa dovrebbe fare il software. Questo aiuta a eliminare i problemi nelle specifiche prima piuttosto che dopo.

Ti dà un senso di progresso.

Ti avvisa se una modifica del codice altera l'output di altre aree di codice. Ciò semplifica il refactoring.

Fornisce un ulteriore livello di documentazione (soprattutto se si commentano correttamente i test).

Incoraggia tutti i tipi di buone pratiche. Poiché i test dovrebbero essere eseguiti velocemente, ti incoraggia a scrivere codice che è disaccoppiato e supporta il derisione. Tutto ciò aiuta il refactoring.

Ce ne sono anche altri trattati in altri post di questa discussione. Ne vale la pena.

Vale la pena provare unit unit o lo sviluppo test-driven?

Sicuramente sì (vedi le altre risposte)

[È] davvero una buona idea e vale la pena lo sforzo e il tempo?

• Sì, se avvii qualcosa di nuovo (aggiungi un nuovo modulo o un'applicazione completamente nuova)
• No, se esiste già un sacco di codice esistente che non è stato sviluppato test-driven e che deve essere esteso (legacy).

A mio avviso, lo sviluppo basato sui test è più efficace se si scrivono i test unitari prima del codice effettivo. in questo modo il codice che soddisfa i test diventa chiaramente separato con un minimo di riferimenti esterni facilmente verificabili.

Se il codice esiste già senza i test unitari, di solito è necessario molto lavoro per scrivere i test unitari in seguito perché il codice non è stato scritto per un facile test.

Se fai TDD, il codice è automaticamente facilmente testabile.

Consentitemi di affrontarlo dall'altra parte. Cosa succede quando si sviluppa un'applicazione non banale senza unit test? Se hai un buon dipartimento di controllo qualità, una delle prime cose che accadrà è che scoprirai di avere un gran numero di problemi segnalati. Perché perché non hai testato quello che hai fatto e hai pensato che avrebbe funzionato e perché non hai prestato molta attenzione ai requisiti e la tua applicazione non li soddisfa. Torna al tavolo da disegno per riscrivere e correggere. Ora hai apportato le correzioni e trovato una serie completamente nuova di problemi perché non avevi modo di verificare che le correzioni non influissero su nessun altro prima di passare al QA. La scadenza di Oops è ormai passata e la gestione è sconvolta.

La situazione è peggiore se non si dispone di un buon dipartimento di controllo qualità perché gli utenti troveranno i bug e non solo ciò renderà il tuo capo infelice, ma potrebbe mettere in ginocchio l'ambiente di produzione e centinaia o addirittura migliaia di persone saranno a un fermo mentre si correggono i bug che il test unitario avrebbe impedito. Questa NON è una buona scelta di carriera.

Supponiamo ora che questo approccio da cowboy continui per anni? Ora ogni cambiamento, anche banale, sembra far emergere nuovi problemi insospettati. Non solo, ma molte delle cose che vorresti fare per far funzionare meglio l'applicazione, non puoi farlo perché sono troppo rischiose o troppo costose o entrambe. Quindi metti le patch sulle patch rendendo il sistema sempre più contorto, più robusto e più difficile da usare.

Gli utenti iniziano a mettere in discussione le stime del tempo perché continuano a diventare sempre più grandi ed è difficile spiegare loro che il sistema è diventato un casino così complicato, è difficile trovare dove apportare le modifiche e ancora più difficile assicurarsi che non facciano ' non rompere qualcos'altro.

Ho lavorato in un posto come questo in cui, dopo dieci anni di sviluppo, praticamente nulla che volevamo fare per risolvere i problemi reali poteva essere fatto perché non sapevamo quale delle centinaia di applicazioni client personalizzate avrebbe funzionato. Gli sviluppatori iniziali erano molto simili a "test unitari, non abbiamo bisogno di puzzolenti test unitari". Tutti coloro che li seguivano soffrivano per la miopia.

Senza test unitari, il software è più complesso e richiede più tempo sia per lo sviluppo iniziale che per la manutenzione. Perché mai non vorresti fare test unitari? Il tempo impiegato per scrivere il test sarà molto inferiore al tempo che impiegheresti a risolvere i problemi che avresti dovuto trovare in precedenza (prima si trova il bug, meno tempo ci vuole per risolvere) e problemi che avresti evitato del tutto scrivendo i test in primo luogo, che consente di comprendere meglio i requisiti prima di iniziare a scrivere codice.

Tutto il codice che scrivi deve essere testato ad un certo punto. Non vuoi scrivere tutto in una volta e poi premere il pulsante di compilazione e incrociare le dita. Scrivi e compili piccoli blocchi e invii input accuratamente elaborati al tuo codice per verificare che faccia quello che pensi che faccia. Quindi, di solito si elimina l'apparecchiatura di test ad hoc e si passa al componente successivo.

Con i test unitari, semplifica questo processo e ti dà una scusa per mantenere i test in giro. In questo modo se apporti modifiche che rompono le cose che hai testato in passato, puoi catturare esplicitamente quella regressione invece di permetterle di influenzare altre parti del codice. C'è un vero valore in questo.

Per quanto riguarda l'approccio del refattore rosso-verde al TDD, lo trovo un po 'noioso. Ma a ciascuno il suo.

La maggior parte delle volte trovo che gli sviluppatori siano resistenti all'idea di scrivere test. Non è tanto che sosterranno che i test non hanno alcun valore, ma piuttosto che sono semplicemente un mezzo per capire come risolvere un particolare problema. Di solito questo problema cambia in base al contesto. Una volta fatto ciò, i test non servono a nulla e potrebbero anche essere eliminati. Ecco un esempio di contesti che i miei colleghi hanno dato in passato su come decidere quando scrivere un test e troverai che l'unica risposta possibile secondo loro non è mai:

• il problema attuale deve essere un esempio di libro di testo per TDD come una pila o una calcolatrice
• il codice banale non deve essere testato (invalida l'argomento precedente)
• il codice critico o difficile dovrebbe essere testato a fondo (implicito nell'argomento precedente)
• i test non dovrebbero essere strettamente associati all'implementazione per consentire un ampio refactoring (invalida l'argomento precedente)
• non è necessario testare gli effetti collaterali come chiamare un servizio di terze parti con un payload specifico (quindi nessun test black box)

In realtà esiste un tipo di test che ho trovato generalmente accettato e che alla fine ritengo inutile. Vale a dire test basati sulla GUI, ad esempio utilizzando selenio, webdriver, watir o arquillian. È così che otteniamo i cicli di build di 7 ore anziché i cicli di build di 5 minuti sui miei progetti TDD.

Questi stessi sviluppatori di solito si lamentano con tutti gli altri per quanto sia cattivo il codice e quanto incompetenti devono essere stati gli sviluppatori precedenti. Trovano inoltre estremamente importante che tu realizzi un design appropriato usando una lavagna, un MS Office o un wiki e prestano molta attenzione a garantire che questo design rimanga aggiornato.

Quest'ultimo è ciò che mi ha davvero fatto capire che tali sviluppatori sono truffe. Sappiamo tutti che qualsiasi documento di progettazione che non è un test unitario diventerà obsoleto e non sarà aggiornato a causa dei costi di manutenzione per farlo. In effetti, ho provato e cercato di trovare un buon mezzo per esprimere idee di design in formato MS Office che fosse utile e leggibile sia prima che dopo il fatto di scrivere codice. Ho fallito in tutti i casi e anche se ci sono persone che riescono a produrre un documento MS Office che sembra carino, non l'ho mai trovato utile.

Quindi hai una scelta. Puoi fare progettazione e documentazione praticando TDD che è l'unico metodo noto e comprovato per produrre tale documentazione sulla base dei miei 10 anni di esperienza di sviluppo. Oppure puoi andare in politica.