Perché è agile tutto sullo sviluppo basato su test (TDD) e non sul test di sviluppo (DDT)?

Uno dei vantaggi di un approccio TDD si realizza solo quando si esegue anche la progettazione emergente.

Quindi, nella tua prima analogia, non scriveresti 100 test, poiché non è possibile sapere come sarà il tuo software.

Scrivi un test. Lo gestisci. Fallisce Scrivi la più piccola unità di codice per far passare il test. Quindi esegui di nuovo il test. Passa.

Ora scrivi il prossimo test, ripetendo il processo sopra.

Questo potrebbe sembrare un approccio dispendioso all'inizio, quando è ovvio che cosa si intende fare il codice, ma la cosa grandiosa di questo approccio è che la copertura del test è sempre alta e il design del codice è più pulito in questo modo.

Come metodo, va di pari passo con la programmazione delle coppie; una coppia scrive il test, il prossimo scrive il codice per farlo passare, quindi scrive il test successivo e così via.

Uso questo approccio anche quando scrivo una nuova classe; il primo test è una chiamata per avviare il costruttore della classe. Ma non ho ancora scritto la lezione, quindi fallisce. Successivamente scrivo la classe semplice, vuota e i miei primi passaggi di prova.

Una volta entrato nella mentalità, è molto difficile non esserci dentro e codificare il modo "vecchio stile".

Consiglierei di lavorare in un buon ambiente Agile per imparare questo, o leggere alcuni buoni libri Agile (Clean Code e Clean Coder sono entrambi molto buoni) per capire meglio.

Il software non è una casa. L'intuizione è buona, ma comprendi che non è sempre corretta.

Break down all the specs into inspection I think I will need (see into the future).

Questo non è accurato. In TDD, stai descrivendo come vuoi usare il codice. Le specifiche dicono "Ci deve essere una casa, con un modo per entrarci". Il test poi dice "Ehi, voglio avere una porta d'ingresso, con una manopola". Questo è lontano meno vedere nel futuro che iniziare con l'implementazione di un doorframe, una manopola, un keylock, ecc. (O così l'argomento va).

Call the inspector back out daily (passing 2/100).

Questo non è corretto. Non stai scrivendo test per la casa. Stai scrivendo i test per il telaio della porta anteriore, rendendoli verdi. Quindi verifica che la porta sia solida, rendendola verde. Dovresti avere forse una dozzina di test al massimo interrotti in qualsiasi momento. Di solito, è più vicino a due a quattro.

Inoltre, l'analogia "chiama l'ispettore fuori" implica che ci vuole un po 'di tempo perché la persona esca e faccia il suo lavoro. Eseguire i test delle unità per un'iterazione TDD dovrebbe letteralmente richiedere alcuni secondi.

It seems like changes can be made faster and without the overhead TDD seem to create.

Il sovraccarico è inferiore a quello che sembra implicare. Qualche secondo per eseguire i test forse una mezza dozzina di volte è irrilevante per il tempo di sviluppo complessivo.

Il problema di dev first è a volte quando si arriva al testing, si scopre che c'è un problema big . Come se tu mettessi il letto vicino al gabinetto e nessuno vuole vivere lì un po 'di problemi. Cose che richiedono più tempo per risolverle rispetto a qualsiasi tipo di sovraccarico TDD. Cose che TDD avrebbe catturato, dal momento che TDD ti obbliga a usare il tuo codice fin dall'inizio e pensa a come interfacciarlo con esso.

My professors in college were all about the idea of Tests then Code then Test.

Tutto ciò che ho detto, TDD non è così onnipresente. Molti posti sono ancora in primo piano e molti dei presunti benefici del TDD sono esagerati. Ciò che è importante è che tu faccia i test e li rendi buoni. L'ordine in cui esegui il lavoro è meno importante.

Le somiglianze tra la creazione di una cosa fisica e il software di scrittura sono piuttosto minime.

Detto questo, c'è un'enorme distinzione che vale la pena sottolineare:

Esiste una differenza tra "creare un test" e "eseguire un test".

Nell'esempio della costruzione di una casa, i requisiti e i test fanno precedono il buildout fisico. E parti della suite di test vengono eseguite in modo continuo - anche da più agenti! Quando il builder prende un 2x4, immediatamente e automaticamente "mette alla prova" l'unità contro la sua idea di "che suono assomiglia a 2x4". Non ha i requisiti dell'autore dopo averlo raccolto; esegue controlli preesistenti su di esso.

Allo stesso modo per un muro assemblato, una scatola elettrica, l'impianto idraulico, ecc. - i test / requisiti esistono già; vengono eseguiti in modo implicito e automatico dagli occhi addestrati di tutti quelli che lavorano in modo continuo . Un'altra serie di test preesistenti viene eseguita quando l'ispettore visita. Se le unità non sono state create per superare quei test preesistenti , falliscono.

E allo stesso modo per la struttura nel suo complesso. I piani preesistono al buildout. Ad ogni passo, gli ingegneri stanno lavorando verso un insieme di condizioni preesistente che alla fine la struttura sarà testata contro quando il buildout è completo.

Detto questo, non tutti i progetti fisici devono essere preceduti da un'enorme serie di test. Se vai al tuo laboratorio e inizi a mettere insieme il legno per una scatola dei giocattoli o qualcosa del genere, lasciando che la tua intuizione e creatività ti guidino, non è una lavorazione del legno TDD rigorosa. In questo caso, ti stai basando fondamentalmente sulle leggi fisiche del medium e sulle tue aspre aspettative di convalidare il lavoro (ad esempio, "se compila e funziona, va bene!").

E va bene. Non tutto deve essere preceduto da test rigorosi.

tl; dr

Anche se costruzione! = software di scrittura: la costruzione funziona in modo guidato dai test. Le condizioni di "passaggio" per ogni unità fanno precedono il loro buildout.

Non confondere "test in esecuzione" con "test di scrittura".

Non tutto deve essere TDD.

Sei caduto nella trappola di credere all'idea assurda che il software di scrittura sia analogo alla costruzione di una casa. Non lo è. È più analogo creare i disegni degli architetti e i calcoli degli ingegneri strutturali.

Ora con le case reali, l'architetto crea questi piani in anticipo. Poi chiama i costruttori, che iniziano a costruire, si imbattono in problemi, devono modificare le cose, ottenere il controllo dell'edificio, chi vogliono i cambiamenti, ecc. Quindi alla fine l'architetto ritorna e ti addebita di più per aggiornare i suoi disegni per riflettere quello che è successo. Questo è un modo scadente di fare le cose, ma le case richiedono molto tempo per essere costruite e costose, quindi è l'unico modo pratico.

Le cose vanno meglio per l'ingegneria del software. L'equivalente dell'edificio sta facendo in modo che il compilatore trasformi il tuo codice in un'unità compilata di qualche tipo (libreria, app, app web, ecc.). È molto veloce ed economico farlo centinaia di volte al giorno. Di conseguenza, non ha senso ricostruire ripetutamente la casa man mano che si aggiungono funzionalità, e solo chiamare l'ispettore (QA) alla fine per testarlo. Invece, se automatizzi questi controlli, puoi fare in modo che l'ispettore riesamini tutto ogni volta che lo ricostruisci.

Se segui un rigoroso TDD, o un approccio più orientato al test di scrivere del codice, allora alcuni test non hanno molta importanza. Preferisco il primo approccio, altri il secondo. Scegli quello che fa per te. L'importante è che tu crei quegli assegni mentre vai avanti. Aiutano in seguito quando si desidera modificare il codice in giro avvisandoti di eventuali interruzioni della funzionalità altrove quando si modifica qualcosa.

Prima di tutto il costo iniziale non è alto come pensi che sia . Sì, passi più tempo ad affrontare i test che se non fai test. Ma se fai un metodo "test dopo" cosa stai veramente sprecando? Diciamo che TDD impiega 10 ore e il DDT impiega 6 ore. I costi iniziali "extra" sono solo 4 ore. Ora se applichi una metrica di codice o un requisito come il 90% di copertura, allora TDD e DDT diventano ancora più vicini nei costi.

Scriverà meno codice bacato con TDD. Anche se è solo perché hai specificato i requisiti come test, alla fine della giornata puoi dimostrare che il tuo codice sta facendo esattamente ciò che volevi che lo facesse. Ora forse volevi che facesse la cosa sbagliata, ma non è un bug che è una richiesta di modifica. Questo è importante. È più facile "vendere" un prodotto che funziona, ma potrebbe funzionare in modo diverso / migliore, quindi è vendere un prodotto che è percepito come non funzionante. Con TDD è letteralmente impossibile superare il test e scrivere codice non funzionante. È possibile che tu non abbia compreso i requisiti e che tu abbia scritto il codice errato, ma funzionante.

TDD è migliore quanto più vecchio diventa il codice base. Prova a refactoring senza una suite di test o con uno poco implementato. Anche un semplice cambiamento può introdurre bug. Avere una suite di test con una buona copertura garantisce che man mano che il prodotto evolve, continua a funzionare come dovrebbe. Aiuta anche a mettere in evidenza le regole aziendali in conflitto (che si verificano in periodi più lunghi).

Non sai che non funziona. Senza una suite di test non sai se il tuo codice funziona come pensi tu o se sembra funzionare.

var foo = function(in) {
    if(in == 0) {
      return true
    }
}

Ora su tutta la tua applicazione chiami if(foo()){ doStuff() } Cosa succede quando aggiusto foo?

var foo = function(in) {
    if(in === 0) {
      return true
    }
}

Dovresti eseguire il refactoring e ASCIUGARE anche i tuoi test. Una buona suite di test non è difficile da mantenere. Con test atomici ben scritti, raramente ho dovuto tornare indietro e cambiarne più di 1-2 alla volta. Quando ci sono stati cambiamenti maggiori nella suite di test, è una gigantesca bandiera rossa che qualcosa non va bene.

I just do not see how I should know all my methods and how things will work until my code is there.

Beh, non dovresti. Dovresti scrivere un test per verificare che alcune unità di lavoro siano state eseguite. Se hai voglia di testare cose che non puoi sapere, allora stai pensando troppo in grande, O il test è troppo piccolo.

Ad esempio, devi sapere che una porta si chiude e si blocca. Vorrei testare door.close () e door.lock () e che door.open () restituisce false quando la porta è bloccata. È così. Se i tuoi test sono door.lock () imposta un flag nel database. Quindi stai testando troppo piccolo. Il test non ha bisogno di sapere come funziona door.lock (), solo che lo fa.

Ora se stai scrivendo un test che dice house.isSecure () restituisce true quando tutte le porte e le finestre sono bloccate. Prima di guardare prima le porte o le finestre, allora stai pensando troppo in grande.

Infine, potresti considerare un'unità di lavoro troppo grande . Quando ottieni il tuo elenco di requisiti, devi organizzarli in modo da lavorare sull'unità più piccola. Scrivi il test solo per quell'unità, quindi il codice, quindi risciacqua e ripeti.

In sostanza, la tua comprensione (l'elenco) di come dovrebbe funzionare TDD è disattivata. Non dovresti mai passare 2/100. Dovresti passare 1/1, passare 2/2, passare 3/3, passare 4/4 e così via.

Una lista rivista per te

1. Ottieni tutte le specifiche
2. Scegli una specifica
3. Provalo
4. Codificalo
5. Provalo
6. Se i test passano, passa a 7 altrimenti vai a 4
7. Se hai fatto tutte le specifiche, vai su 8 altrimenti vai su 2
8. Rivedere le specifiche con il consumatore e aggiungere nuove specifiche dove necessario. Se fatto correttamente non dovresti dover cambiare nessun test. Basta aggiungerne di nuovi. A volte la raccolta dei requisiti può cadere a pezzi e devi aggiungere test in conflitto con i test precedenti, ma raramente devi cambiare test.

Ci sono alcuni tasti che ritengo mancano le altre risposte.

Tre vantaggi

In primo luogo, il costo dell'errore e il costo del cambiamento sono così incredibilmente diversi tra software e una casa che alcune regole potrebbero non essere applicabili. Ad esempio, il costo di testare una struttura fisica è così elevato che è necessario un elevato livello di sicurezza perché funzioni in modo da non sprecare test. Con il software, se puoi eseguire una suite di test unitari in 1 - 5 secondi, allora abbiamo a disposizione diverse opzioni.

In secondo luogo, lo scopo dell'esecuzione di un test che si prevede di fallire prima di scrivere il codice sotto test è di verificare il test stesso. Certo, può sembrare sciocco o dispendioso. Ma ho visto abbastanza test unitari scritti in un modo che passerà sempre, anche quando il codice sotto test è rotto. Ciò può facilmente accadere quando scrivi il codice sotto test, lo collaudi manualmente, quindi scrivi il test unitario. Se scrivi un test unitario, vedi fallito, quindi quando scrivi il codice necessario per farlo passare e passa, sai che il tuo test è valido. Se il code-under-test regredisce, c'è una ragionevole possibilità che il test dell'unità lo catturi.

Un terzo vantaggio per TDD, non menzionato spesso, è che le dimensioni e la complessità del codice risultante sono spesso di un ordine di grandezza inferiore. Mi sono sempre vantato di preferire il codice semplice e conciso. Fino a quando ho iniziato a praticare TDD. TDD mi ha mostrato che quello che avrei fatto prima sarebbe stato un codice eccessivo. Perché succede? Perché scrivi un test, quindi scrivi il codice per far passare il test. Al termine del test, hai finito. Se ti trovi in questa mente, è difficile scrivere accidentalmente un codice "extra".

(Il codice aggiuntivo è stato un problema che ho riscontrato in un prodotto su cui lavoravo. Problemi gravi derivanti da codice non richiesto da nessuno, ma alcuni sviluppatori hanno pensato che sarebbe stato interessante.)

Analisi costi

Quindi, in qualche modo, hai ragione. Non siamo riusciti a farla franca con questa strategia quando costruiamo una casa. Sarebbe troppo costoso. Ma il software non è una casa. Il software è economico.

Un'analogia con una casa è il lavoro di assemblare la casa contro un compilatore di software.

In un mondo non TDD, gli sviluppatori continuano a ripetere. Seguiamo un codice - > compila - > corri - > ciclo di prova. Siamo già in un modello che si discosta sostanzialmente dalla costruzione di una casa. Se i tuoi costruttori costruiscono un telaio per porte, poi costruiscono una porta, quindi devono ricostruire il telaio perché la porta è troppo grande per questo, avrai un problema di costi. Quindi, trascorri più tempo in anticipo per assicurarti di ottenere tutto perfetto. Nella programmazione, la maggior parte dei progetti può essere compilata in pochi secondi o minuti, quindi non importa se qualcosa è imperfetto nelle prime fasi. Il costo di pensare a questioni banali in anticipo supera generalmente il costo della ricompilazione. Pertanto, ricompiliamo continuamente.

TDD è lo stesso principio, appena ruotato in modo che il test vada avanti. Se il test può essere reso super economico (quindi funziona tutto in pochi secondi), allora il costo di pensare attraverso il quadro generale, la soluzione perfetta e globale in un'unica iterazione di codifica big-bang supera il costo del refactoring.

Solo che ...

Ci sono alcune cose nella programmazione in cui questi argomenti non reggono. Questo è lo scopo dell'architettura. Identificare e pianificare le preoccupazioni iniziali che saranno più costose da cambiare in seguito. Ad esempio, non si sceglie un database al volo senza pensare alle proprie esigenze, iniziare a costruire e semplicemente sostenere che è possibile modificarlo in seguito. Devi pensarci su.

Di solito mi chiedevo molto di questo fino a quando non ho realizzato alcuni progetti di TDD. C'è una spiegazione molto succinta e completa che mi è venuta in mente mentre lo facevo:

Quando scrivi il codice devi avere un modo per assicurarti che il codice faccia qualcosa di significativo. Quindi testerai il tuo codice. Puoi fare test ad hoc. Tuttavia, il test funziona meglio se pensi a come testare prima di iniziare a fare le cose. Quindi progetta la strategia di test prima di andare al test.

Ora, dal momento che stai pensando alla tua strategia di test, potresti anche automatizzare, almeno una parte di esso ... Ed ecco che hai un certo livello di TDD. Il fatto di scrivere codice fino a superare il test è normale. Questo è quello che fai comunque, scrivi il codice finché non funziona. È solo ora facile far saltare i test.

Per ragioni che vanno oltre l'ambito non scrivi l'intera cosa in un colpo solo. Quindi non progettare i test in un colpo solo. Ma in fondo è quello che è. Solo una migliore pianificazione dei test, non sempre si scrive test in anticipo. A volte ne aggiungi di più man mano che progredisci e trovi bug che non avevi previsto o che renderebbero il test più robusto in seguito. E a volte potresti non trovarti a progettare test, ma trovare test manuali laboriosi in modo da eseguire i test più tardi.

Quindi TDD è solo un modo estremo di vedere come convalidare il tuo lavoro.

Anche se questa domanda ha già una risposta accettata, credo di aver qualcosa da aggiungere, derivante da uno stile di progettazione non scritto (tutti i test eseguiti manualmente da "tester" seguendo una procedura di test) a TDD. Queste sono solo le mie osservazioni personali, anche se credo che siano abbastanza universali.

Quando scrivi qualcosa di nuovo, qualcosa che non hai mai fatto prima, non c'è alcuna differenza significativa tra TDD e non fare TDD.

Generalmente ciò che faresti è scrivere una piccola porzione di codice per esplorare un'idea, quindi aggiungere alcuni bit codificati per "testare" e quindi compilarli e / o eseguirli. Se funziona, elimineresti il materiale hardcoded e generalizzeresti il codice aggiungendo parametri, variabili di istanza, ecc.

Pensaci. È esattamente la stessa quantità di lavoro di TDD. L'unica differenza è in TDD, si scrivono i bit "testing" separatamente in un altro file e non vengono eliminati alla fine. In TDD mantieni il tuo codice di test .

Naturalmente, il TDD è leggermente più organizzato significa che c'è un po 'più di lavoro per capire come separare i bit di test del codice dal tuo codice reale. Ma se hai scritto dei test unitari prima di imparare a modulare il codice per il test.

Why is agile all about the test-driven development (TDD) and not development-driven test (DDT)?

Cinguettando qui dentro perché trovo che la domanda suggerisca un fatto ("l'agilità riguarda tutto il TDD") che trovo piuttosto discutibile. Tutte le risposte sembrano dare per scontato questo fatto. Sono buone risposte se si presuppone che l'agilità riguardi principalmente TDD (a.k.a., test a livello di unità).

Il link elenca una buona dozzina o più diversi modelli di sviluppo.

Offrire uno sviluppo orientato al comportamento e uno sviluppo basato su funzionalità come spunto di riflessione. Animali completamente diversi che anche possono portare a tutti i benefici del TDD di base, ma sono ben lontani da un semplice ciclo refact rosso-verde.

Quindi la mia risposta è:

• "DDT" (a.k.a., scrivere test dopo o "in cima" all'implementazione) non funziona per motivi di vita reale; non appena si ottiene la pressione del tempo o dei soldi, i test vanno fuori dalla finestra; e il solo fatto di test per il beneficio di test è piuttosto meh, IMO.
• Agile è non tutto sullo sviluppo basato sui test (TDD) se interpretate quel termine come fondamentalmente "test unitari per tutti i blocchi / classi" (che, almeno secondo Wikipedia, è il caso). TDD è solo una possibilità di fare uno sviluppo agile.
• Ci sono altri metodi, come BDD o FDD, che fanno un approccio a stack completo. Scrivi ancora i tuoi scenari in anticipo, hai ancora un ciclo refact rosso-verde, e continui a implementare solo fino a quando i tuoi scenari sono verdi, ma i tuoi "test" per definizione esercitano l'intero software (agendo come l'interazione dell'utente) e mai solo una singola unità.

Preferirei avere un'applicazione con copertura BDD / FDD completa e nessun test unitario di uno con copertura completa del test unitario e nessun test full-stack.

(TDD ha il suo posto, naturalmente, ad esempio nelle API, ma non è quello di cui stiamo parlando qui.)

Ancora una volta, non sto tentando di mettere sottosopra tutte le altre risposte qui, sottolineando solo che la domanda è formulata piuttosto stretta, e il campo ha molto più da offrire.

Anche se non lo vedi spesso scritto in questo modo, gran parte del ragionamento dietro l'agilità è che riscrivere il codice è meglio che scriverlo bene la prima volta. Ogni volta che riscrivi il codice, migliori il codice e migliorati. Ottenendolo "Giusto" la prima volta tende ad essere più lento e più fragile.

L'analogia della casa non è poi così male, ma devi pensare a quanto tempo abbiamo conosciuto sulla costruzione di case rispetto a quanto tempo abbiamo conosciuto sull'ingegneria del software - anche la complessità dell'ingegneria del software è più vicina alla costruzione un lungo ponte o una torre di 20 piani di una casa. Dovremmo anche considerare che con nuovi linguaggi e strumenti in costruzione è come se ogni costruttore volesse costruire l'edificio con forme, dimensioni e materiali completamente diversi. Completa il caos.

Tuttavia, l'ispezione non è una buona analogia con il test del codice. Nel software non siamo nemmeno al punto in cui ABBIAMO ispettori decenti (eccetto i tuoi compagni di vari livelli di abilità). Inoltre, non abbiamo regole da ispezionare tranne, forse, alcuni "standard di codifica" per lo più arbitrari (il che è più simile alla verifica del colore della vernice e del layout del prato rispetto alla struttura).

Il primo test è più simile a come si costruisce un muro, quindi si esercita una certa pressione su di esso per garantire la stabilità prima di sollevarlo e posizionarlo sulla propria casa. È come misurare la finestra per assicurarti che si adatti alla buca che hai lasciato prima di provare a posizionarla.

Se dovessi costruire una serie di ponti senza i nostri secoli di conoscenza dell'architettura precedente, schemi, normative e matematica che attualmente dobbiamo dimostrare che i nostri ponti funzioneranno prima di costruirli, probabilmente verificherai e ricostruirai i tuoi ponti MOLTO.

Infine un punto di non-analogia - con il software ogni volta che ti è permesso di riscrivere una sezione del tuo codice, migliori il tuo codice e la tua abilità in modo significativo. Prendi tutte le possibilità che puoi per riscrivere il codice. TDD può essere un'ottima scusa.