Il testing dell'unità o lo sviluppo basato sui test sono utili?

Risposta breve: assolutamente positivo.

Risposta lunga: i test unitari sono una delle pratiche più importanti che cerco e influenza sul mio posto di lavoro (grande banca, trading fx). Sì, sono lavori extra, ma è un lavoro che ripaga ancora e ancora. I test unitari automatizzati non solo ti aiutano a eseguire il codice che stai scrivendo e, naturalmente, verificano le tue aspettative, ma agiscono anche come una sorta di cane da guardia per i futuri cambiamenti che tu o qualcun altro potrebbero fare. La rottura del test si verifica quando qualcuno cambia il codice in modi indesiderati. Penso che il valore relativo dei test unitari diminuisca in correlazione con il livello di cambiamento atteso e crescita in una base di codice, ma la verifica iniziale di ciò che il codice fa valga la pena anche dove il cambiamento atteso è basso. Il valore del test unitario dipende anche dal costo dei difetti. Se il costo (dove il costo è la perdita di tempo / denaro / reputazione / sforzo futuro) di un difetto è zero, allora anche il valore relativo di un test è zero; tuttavia questo non è quasi mai il caso in un ambiente commerciale.

Generalmente non assumiamo più persone che non creano abitualmente test unitari come parte del loro lavoro - è solo qualcosa che ci aspettiamo, come alzarci ogni giorno. Non ho visto una pura analisi costi-benefici di test unitari (qualcuno si sente libero di indicarmi uno), tuttavia posso dire per esperienza che in un ambiente commerciale vale la pena provare il funzionamento del codice in un grande sistema importante . Inoltre, mi consente di dormire meglio di notte sapendo che il codice che ho scritto funziona in modo dimostrabile (fino a un certo livello), e se cambia qualcuno verrà avvisato di eventuali effetti collaterali imprevisti causati da una build danneggiata.

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

In assenza di prove matematiche per te che ha senso scrivere test unitari, ti incoraggio a provarlo per un periodo prolungato e a sperimentare personalmente i vantaggi.

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. Investisci un po 'di più in anticipo, ma riprendilo più tardi. Il grafico è un po 'esagerato, ma mostra bene l'idea.

Image Source

It seems like writing tests is extra work, gives people a crutch when they write the real code, and might not be effective very often.

Il test unitario ha valore come stampella. Supporta i tuoi sforzi di sviluppo, permettendoti di cambiare la tua implementazione senza temere che la tua applicazione smetta di funzionare come richiesto. I test unitari sono anche molto più di una stampella, dato che ti danno uno strumento con cui puoi verificare che la tua implementazione corrisponda ai requisiti.

Tutti i test, sia che si tratti di test unitari, test di accettazione, test di integrazione e così via, sono efficaci quanto quelli che li utilizzano. Se ti avvicini al tuo lavoro in modo sconsiderato, i tuoi test saranno sciatti e la tua implementazione avrà dei problemi. Allora perché preoccuparsi? Ti impegni a testare perché devi dimostrare a te stesso e ai tuoi clienti che il tuo software funziona e non ha alcun problema che potrebbe impedire l'utilizzo del software. Sì, i test sono sicuramente un lavoro extra, ma il modo in cui procedi con i test determinerà quanto impegno dovrai porre per correggere i bug dopo il rilascio e quanto impegno richiederà il codice per cambiare e mantenere.

I understand how unit tests work and how to write them, but can anyone make the case that it's really a good idea and worth the effort and time?

TDD, e davvero qualsiasi metodo che richiede di scrivere test prima che il codice prenda l'approccio che hai messo in atto in anticipo come un acconto sul debito tecnico futuro. Mentre lavori attraverso il progetto, tutto ciò che viene perso, o non implementato correttamente, incorre in un debito più tecnico sotto forma di maggiori difficoltà di manutenzione, che influisce direttamente sui costi futuri e sui requisiti di risorse. Testare in anticipo assicura che non solo ti sei sforzato di affrontare il debito tecnico futuro, ma anche di codificare le tue esigenze in modo tale che possano essere verificate semplicemente eseguendo il tuo codice. Il primo test 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.

Si tratta davvero di cercare 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 a fondo a livello di unità è generalmente più costoso da creare, ma costa relativamente poco da mantenere per tutta la durata del prodotto dopo il rilascio.

Also, is there anything that makes TDD especially good for SCRUM?

Il TDD non è specifico per una particolare metodologia. È semplicemente uno strumento. Una pratica che puoi integrare nei tuoi processi di sviluppo per 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.

Is unit testing or test-driven development worth while?

Sì, . Uncle Bob (Robert C Martin) raccontato in a in una presentazione;

For a developer to prove that his code is working better to write a test and pass it than shouting , singing or dancing about it.

E dal momento che non cancellerai il test, finché il test è un passaggio sei sicuro 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 funzionalità. Scrivi un test. Fallo e basta.
2. Quando sostituire i test delle unità con Test di integrazione

Are SCRUM, Unit testing and TDD related?

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

Is there anything that makes TDD especially good for SCRUM?

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

Le persone pensano che sia uno sforzo extra perché è un'attività in prima fila. Quello che perdi in tempo, ora ti riacquisti più tardi.

Le mie ragioni per il test delle unità includono anche:

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

Ti dà un senso di progresso.

Avvisa se un cambio di codice altera l'output di altre aree di codice. Ciò facilita il refactoring.

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

Incoraggia tutti i tipi di buone pratiche. Poiché i test devono essere eseguiti rapidamente, ti incoraggia a scrivere codice disaccoppiato e che supporta il mocking. Questo aiuta tutti a refactoring.

Ce ne sono altri coperti in altri post in questa discussione. Ne vale la pena.

Is unit testing or test-driven development worthwhile?

Sicuramente sì (vedi le altre risposte)

[Is it] really a good idea and worth the effort and time?

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

A mio parere, 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 che è facilmente testabile.

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

Se fai TDD il codice automaticamente è facilmente testabile.

Permettimi di avvicinarmi a questo dall'altra parte. Cosa succede quando sviluppi un'applicazione non banale senza test unitari? Se hai un buon dipartimento di QA, una delle prime cose che accadrà è che troverai un gran numero di problemi segnalati. Perché, perché non hai verificato ciò che hai fatto e hai pensato che avrebbe funzionato e perché non hai prestato molta attenzione ai requisiti e la tua applicazione non li ha soddisfatti. Oops torna al tavolo da disegno per riscrivere e correggere. Ora hai apportato le correzioni e trovato un nuovo set di problemi perché non hai avuto modo di verificare che le tue correzioni non abbiano influito su nessun'altra cosa prima di essere spinto al QA. La scadenza di Oops è ormai terminata e la gestione è sconvolta.

La situazione è peggiore se non si dispone di un buon dipartimento di controllo qualità perché gli utenti troveranno gli errori e non solo renderanno il capo infelice, ma potrebbero portare l'ambiente di produzione in ginocchio e centinaia o addirittura migliaia di persone sarà fermo mentre si sistemano i bug che il test dell'unità avrebbe impedito. Questa NON è una buona scelta di carriera.

Supponiamo che questo approccio da cowboy continui per anni? Ora ogni cambiamento, anche banale, sembra far sorgere 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 le cose. Quindi metti le patch sulle patch rendendo il sistema sempre più complicato, più bugger 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 persino apportare le modifiche e ancora più difficile accertarsi non infrangono qualcos'altro

Ho lavorato in un posto come questo dove dopo dieci anni di sviluppo, praticamente non volevamo fare nulla per risolvere i veri problemi, perché non potevamo stabilire quale delle centinaia di applicazioni client personalizzate si sarebbero interrotte. Gli sviluppatori iniziali erano in gran parte i "test unitari, non abbiamo bisogno di test di unità puzzolenti" tipo di sviluppatori. Tutti coloro che li hanno seguiti hanno sofferto grazie alla loro miopia.

Senza test unitari, il software è bugger e richiede più tempo per lo sviluppo e la manutenzione iniziali. Perché mai non vorresti fare test unitari? Il tempo che dedichi a scrivere il test sarà molto inferiore al tempo che avresti speso per risolvere problemi che avresti dovuto trovare prima (prima si trova il bug meno tempo ci vuole per risolvere) e problemi che avresti evitato del tutto scrivendo i test per prima cosa dà una migliore comprensione dei requisiti prima di iniziare la codifica.

Tutto il codice che scrivi deve essere testato ad un certo punto. Non vuoi scrivere tutto in una volta sola, quindi premi il pulsante di compilazione e incrocia le dita. Scrivi e compila piccoli blocchi e invia input accurati al tuo codice per verificare che faccia ciò che pensi che faccia. Quindi, di solito elimini il tuo apparecchio di prova ad-hoc e passerai al componente successivo.

Con il test delle unità, semplifica questo processo e ti dà una scusa per mantenere i tuoi test in giro. In questo modo, se apporti delle modifiche che interrompono le cose che hai testato in passato, puoi rilevare la regressione in modo esplicito invece di permetterle di influenzare altre parti del tuo codice. C'è un valore reale in questo.

Per quanto riguarda l'approccio red-green-refactor a TDD, trovo che sia un po 'noioso. Ma a ciascuno il suo.

Il più delle volte trovo che gli sviluppatori sono elastici all'idea di scrivere test. Non è così tanto che sostengono che i test non hanno valore, ma piuttosto che sono solo un mezzo per capire come risolvere un particolare problema. Di solito questo problema cambia in base al contesto. Una volta fatto, i test non hanno alcuno scopo e potrebbero anche essere cancellati. Ecco un esempio di contesti che i miei colleghi hanno dato in passato su come decidere quando scrivere un test e scoprirai che l'unica risposta possibile secondo loro non è mai:

• il problema in questione deve essere un esempio di libro di testo per TDD come una pila o un calcolatore
• il codice triviale non dovrebbe essere testato (invalida l'argomento precedente)
• il codice critico o difficile deve essere accuratamente testato (implicito dall'argomento precedente)
I test
• non devono essere strettamente accoppiati all'implementazione per consentire il refactoring di sweeping (invalida l'argomento precedente)
• test per effetti collaterali come chiamare un servizio di terze parti con un payload specifico non è necessario (quindi nessun test black box)

In realtà c'è un tipo di test che ho trovato è generalmente accettato e che credo sia in definitiva inutile. Ovvero test basati su GUI come l'utilizzo di selenio, webdriver, watir o arquillian. Questo è il modo in cui otteniamo i cicli di generazione di 7 ore invece dei 5 minuti di cicli di sviluppo sui miei progetti TDD.

Questi stessi sviluppatori di solito si lamentano con tutti gli altri quanto il codice sia dannoso e quanto gli sviluppatori precedenti debbano essere stati incompetenti. Trovano inoltre estremamente importante che tu faccia un progetto adeguato usando una lavagna, un ufficio MS o una wiki e stai molto attento a garantire che questo design rimanga aggiornato.

Quest'ultimo è ciò che mi ha veramente fatto capire che questi sviluppatori sono frodi. Sappiamo tutti che qualsiasi documento di progettazione che non è un test unitario diventerà obsoleto e non sarà aggiornato per via degli onerosi costi di manutenzione. In effetti, ho provato e cercato di trovare un buon mezzo per esprimere idee di progettazione nel formato MS Office che fosse utile e leggibile sia prima che dopo la scrittura del codice. Ho fallito in tutti i casi e anche se ci sono persone che riescono a produrre un documento di MS Office che sembra carino, non ho mai trovato quelle utili neanche.

Quindi, hai una scelta. Si può fare progettazione e documentazione praticando TDD, che è l'unico metodo conosciuto e provato per produrre tale documentazione sulla base dei miei 10 anni di esperienza nello sviluppo. Oppure puoi entrare in politica.