Quali sono gli svantaggi della scrittura del codice prima di scrivere i test unitari?

Il rosso è la risposta. Il rosso è ciò che ottieni dal ciclo di refattore rosso-verde di TDD che non puoi ottenere, testare per ultimo. Per prima cosa, scrivi un test fallito. Guardalo fallire. Questo è il tuo rosso ed è importante. Dice: ho questo requisito e io so il mio codice non lo soddisfa. Quindi, quando vai al punto 2 (verde), sai, con altrettanta certezza, che il tuo codice ora soddisfa quel requisito. Sai che hai cambiato la tua base di codice in modo tale da soddisfare il requisito.

I requisiti (test) sviluppati dopo il codice, basati sul codice, ti privano di quel tipo di certezza, quella confidenza.

Se scrivi il codice e poi i test, è fin troppo facile cadere nella trappola di scrivere i test in modo che il codice passi, piuttosto che scrivere i test per garantire che il codice soddisfi le specifiche.

Detto questo, non è sicuramente l'unico modo di fare le cose, e non esiste un modo "migliore" per sviluppare software. Se metti un sacco di lavoro in anticipo nello sviluppo di casi di test, non sai se la tua architettura proposta ha qualche difetto fino a molto più tardi - mentre se hai sviluppato il codice prima, ti imbatterai prima e potrai riprogettarlo con meno sprofondato sforzo.

In realtà, la gente si blocca su TDD parla di test, anche se dimenticano le altre due lettere nell'acronimo. Qualcosa che può essere letto qui: TDD senza T o TDD non riguarda il test .

Il fatto è che ho appreso una pletora di altre cose che sono strettamente legate al TDD. Non importa se esegui prima il test: Ciò che conta è pensare alla progettazione del software .

Per essere in grado di scrivere unit test "nel modo giusto", cioè in modo che siano isolati, rapidi e automatizzati, noterai che ci vorrà qualche ripensamento su come organizzare il tuo codice in un modo che il tuo codice diventa più facile da testare.

Personalmente ho imparato a conoscere i principi SOLID senza sapere che c'era una cosa scritta. Questo perché i test delle unità di scrittura mi hanno costretto a riscrivere le classi in modo che non diventino eccessivamente complesse da testare. Ha portato a cose come:

• Ho dovuto spostare la funzionalità, che non aveva senso o risiedeva in metodi privati, oltre a separare le classi in modo da poterle testare separatamente. (Principio della singola responsabilità).
• Ho dovuto evitare grandi strutture di ereditarietà e estendere le implementazioni con la composizione (preminente nel principio Open-Closed).
• Dovevo essere intelligente sull'ereditarietà, ho usato classi astratte ogni volta che ho visto un codice comune che poteva essere condiviso e usato i metodi di stub (Principio di sostituzione di Liskov).
• Ho dovuto scrivere interfacce e classi astratte in modo da poter testare le classi in seperazione. Che inavvertitamente ti porta a scrivere oggetti finti. (Principio di segregazione dell'interfaccia)
• Poiché ho scritto molte interfacce e classi astratte, ho iniziato a dichiarare variabili e parametri per utilizzare il tipo comune (principio di inversione delle dipendenze).

Anche se non lo faccio mai per sempre, mi capita di seguire i buoni principi OO e le pratiche che inizi a seguire, solo per rendere il test un po 'più facile. Ora non sto scrivendo il codice fine a se stesso. Ho scritto il codice in modo che possa essere facilmente testato o più importante; facilmente gestito .

Tutte le altre risposte sono buone, ma c'è un punto che non è stato toccato. Se scrivi prima il test, questo assicura che i test vengano scritti. È allettante, una volta scritto il codice di lavoro, saltare i test e verificarlo tramite l'interfaccia utente. Se hai la disciplina per avere sempre un test falloso prima di scrivere il codice, puoi evitare questa trappola.

Se scrivi prima i test, ti dà un'altra possibilità di pensare al tuo design, prima che il design sia "scolpito nella pietra".

Ad esempio, potresti pensare di aver bisogno di un metodo che accetta un certo insieme di parametri. E se prima scrivevi il codice, lo scrivesti in quel modo e rendi il test adatto ai parametri specificati. Ma se scrivi prima il test, potresti pensare "aspetta un attimo, non vorrei usare questo parametro nel codice mainline, quindi forse dovrei cambiare l'API."

As I see a lot of recommendations to start writing tests and then move on to coding,

C'è una vera buona ragione per questo.

Se dici "fai ciò che sembra giusto", le persone fanno le cose più stupide e più folli.

Se dici "scrivi prima i test", le persone potrebbero almeno provare a fare la cosa giusta.

what are the disadvantages if I do it the other way - write code and then the unit tests?

Di solito, un test scadente e un progetto che devono essere rielaborati per essere testabili.

Tuttavia, questo è solo un "di solito". Alcune persone evolvono i progetti e i test in parallelo. Alcune persone inseriscono il codice verificabile e scrivono test senza rielaborazione.

La regola "Prima prova" è specificamente lì per insegnare e istruire le persone che non hanno alcun indizio.

In modo simile, ci viene detto di guardare sempre "entrambi i modi" prima di attraversare la strada. Tuttavia, in realtà non lo facciamo. E non importa. Vivo in un paese con guida a destra e ho solo bisogno di guardare a sinistra quando si inizia ad attraversare.

Quando visito un paese con guida a sinistra, guardare solo a sinistra potrebbe farmi uccidere.

Le regole sono enunciate in modo molto strong per un motivo.

Quello che fai è il tuo problema.

il punto di scrivere il test prima è che ti fa pensare

• come testare il codice
• l'interfaccia che il codice deve presentare per essere testabile

se stai facendo qualcosa di semplice, probabilmente non importa quale scrivi per prima (anche se è bene coltivare l'abitudine al test) poiché il test sarà semplice e l'interfaccia sarà ovvia

ma TDD si trasforma in test di accettazione, non solo in unit test, e quindi l'interfaccia diventa non banale.

Innanzitutto, se non scrivi prima i test, allora non stai facendo il Test Driven Development (TDD). I benefici sono numerosi e spesso difficili da credere finché non lo pratichi più volte. Ecco i vantaggi che ho ricevuto facendo TDD rispetto allo sviluppo tradizionale:

1. Una rete di sicurezza di test - consente di apportare grandi cambiamenti senza la paura di rompere qualcosa inconsapevolmente
2. Design organico: il design che ho alla fine è di solito diverso dal design che avrei fatto da zero ed è sempre stato migliore
3. Produttività - lavorare verso piccoli obiettivi (superare questo test) e farlo (tutti i test superano) funziona davvero bene per me e mi mantiene motivato. Aggiungi una coppia e la mia produttività raggiunge nuovi massimi.

Libri: Beck, K. Sviluppo basato sui test con l'esempio

Buon esempio: link

Quando scrivi un test, come fai a sapere che rileverà una condizione di errore? La risposta è "prova il test". Come si fa è di scrivere prima il test, vederlo fallire e vederlo passare solo quando l'unità in prova è stata codificata con successo (il ciclo rosso / verde / refactor menzionato in una delle altre risposte).

Scrivendo prima il codice e poi il test lascia aperta la domanda se il test mostrerebbe un errore onesto.

Ricorda che i test esprimono le specifiche. Se devi rivedere i test mentre il tuo codice "si adatta", suggerisce che le tue specifiche stanno cambiando. Potrebbe essere o non essere una buona cosa. Potrebbe significare che la tua comprensione del problema non era inizialmente corretta. D'altra parte, potrebbe significare che stai testando "come" l'unità sta facendo il suo lavoro piuttosto che cosa si suppone stia facendo.