TDD solo in teoria

Poco più di un anno fa sono stato abbastanza fortunato da riuscire a prendermi una pausa di 9 mesi dal lavoro. Ho deciso che in quel momento avrei affinato le mie abilità in C #. Ho iniziato a lavorare su diversi progetti e mi sono costretto a seguire il TDD.

È stato un processo abbastanza illuminante.

All'inizio è stato difficile, ma nel tempo ho imparato a scrivere codice più testabile (che, a quanto pare, tende ad essere più codice SOLID) e nel processo ho anche affinato la mia abilità di progettazione OO.

Ora sono tornato nella forza lavoro e sto notando qualcosa di strano.

Preferisco non seguire TDD.

Trovo che TDD mi rallenta e in realtà rende più difficile progettare un'applicazione pulita.

Invece, ho adottato un approccio leggermente (enormemente diverso):

1. Scegli una fetta verticale di lavoro
2. Sviluppa un prototipo funzionante
3. Rifattore fino a quando tutto è bello e ordinato
4. Siediti e apprezza il bellissimo codice SOLID e testabile che ho scritto.

Potresti aver notato che il passaggio 1 non era "definire la superficie pubblica del mio obiettivo di prova" e il passaggio 2 non era "testare il bejesus da detta superficie pubblica". Potresti anche aver notato che nessuno dei passaggi prevede test. Sto scrivendo codice testabile, ma non lo sto testando ... per ora.

Ora, vorrei chiarire che in realtà non sto rinunciando a nessun tipo di test. Il codice che sto scrivendo funziona . Funziona perché lo sto testando manualmente.

Vorrei anche chiarire che non sto rinunciare a tutti i test automatici. Questo è dove il mio processo è diverso. Ed è per questo che sto ponendo questa domanda.

TDD in teoria. Non in pratica.

Il mio processo si è evoluto un po 'e ho trovato un equilibrio tra TDD e nessun test che trovo molto produttivo e anche ragionevolmente sicuro. Va come segue:

1. Implementa una porzione di lavoro verticale funzionante tenendo presente i test, ma non scrivere alcun test.
2. Se lungo la strada (ad esempio, un mese dopo) quella sezione deve essere modificata
   1. Scrivi test unitari, test di integrazione, test comportamentali, ecc. Che garantiscano che la porzione di lavoro sia corretta
   2. Modifica il codice
3. Se quella sezione non necessita di modifiche,
   1. Fare niente

Spostando semplicemente l'onere della scrittura dei test da prima di scrivere il codice a prima di modificare il codice sono stato in grado di produrre molto più codice funzionante. E, quando vado in giro a scrivere test, ne scrivo molto meno ma copro quasi altrettanto terreno (ROI più elevato).

Mi piace questo processo, ma temo che potrebbe non adattarsi bene. Il suo successo dipende dal fatto che gli sviluppatori siano diligenti nello scrivere test prima che cambino le cose. E questo sembra un rischio piuttosto grande. Ma TDD ha lo stesso rischio.

Quindi, vado all'inferno [BT] DD, o è una forma comune di codifica e test pragmatici?

Mi piacerebbe continuare a lavorare in questo modo. Cosa posso fare per far funzionare questo processo a lungo termine?

Sono l'unico sviluppatore dei miei progetti e sono responsabile di tutto: raccolta dei requisiti, progettazione, architettura, test, implementazione, ecc. Sospetto che sia per questo che il mio processo sta funzionando.

Per far funzionare il processo a lungo termine, scriverei i test quando il codice viene scritto.

Che può sembrare contraddire il tuo approccio. Comunque hai posto la domanda, quindi ti darò la mia opinione:

Non è necessario scrivere i test prima del codice. dimentica quella purezza. Tuttavia, si desidera scrivere i test in quel periodo.
Una volta che hai fatto funzionare il codice, l'hai modificato un po ', eliminato alcuni bug (stiamo parlando di una scala temporale di ore qui), allora sei a un punto della massima conoscenza di ciò che il codice sta facendo. Questo è un ottimo momento per scrivere test che catturino le tue conoscenze.

Lasciare questo fino a dopo significa che la conoscenza (naturalmente) diminuirà nel tempo.

Significa anche che se dovessi mai andartene e se qualcun altro dovesse prenderti il ​​controllo, non avrai il debito tecnico immediato di non aver documentato (attraverso i test) cosa fa cosa.

Soprattutto, "un giorno" potrebbe non venire. Potresti essere investito da un autobus o salire a bordo dell'autobus per nuove avventure.

Infine, i test manuali non si adattano e spesso non coprono tutti i dispositivi utilizzati dall'utente finale.

Sebbene TDD sia difficile da implementare al 100%, c'è un difetto nel tuo approccio

1. Implementare una porzione di lavoro verticale funzionante

   1.1 Passano 1 anno ....

   1.2 Un nuovo sviluppatore inizia a lavorare sul progetto

2. Se quella sezione deve essere modificata

   2.3 Nomi e parametri del metodo di stile "Clean Coding" "GetUnicorn (colourOfUnicorn)"

   2.4 Leggi i commenti xml "Ottiene un unicorno d'oro (per la guida) (obvs)"

   2.5 Dai la caccia allo sviluppatore originale

   2.6 Spero che ricordino cosa dovrebbe fare il codice

   2.7 Fagli spiegare tutto

3. Scrivi test unitari, test di integrazione, test comportamentali, ecc. Che, si spera, garantiscono che la porzione di lavoro sia corretta

4. Modifica il codice

Penso che sia corretto identificare che i test unitari mostrano davvero il loro valore quando sono necessarie modifiche.

Sono d'accordo sia con Daniel Hollinrake che con Ewan, sul fatto che il primo punto chiave per cui il tuo test-only-if-modifica funziona bene finora è:

I am the sole developer on my projects and I am responsible for everything

e che un probabile secondo punto chiave è:

you're producing nice clean code

Non penso che TDD apporti un enorme aumento della produttività per i soli programmatori e potrebbe non migliorare enormemente la qualità del tuo codice se stai già scrivendo un buon codice pulito.

Tuttavia, TDD migliorerà sicuramente la qualità del codice di programmatori poveri / inesperti / obsoleti, specialmente quando arriva il momento di modificare il codice senza interrompere altro. E ancora di più se la persona che modifica il codice non è la stessa persona che ha scritto il codice in origine o sono trascorsi diversi mesi.

In altre parole, penso che TDD sia una buona pratica per migliorare la qualità del tuo codice (come ti riconosci), ma anche (e più importante) una sorta di copertura quando lavori con programmatori medi o mediocri (diciamo, da un diverso dipartimento o una società diversa) che è una situazione molto più comune di lavorare da soli.

Per me la cosa chiave sembra essere questa:

Sono l'unico sviluppatore dei miei progetti e sono responsabile di tutto: raccolta dei requisiti, progettazione, architettura, test, implementazione, ecc. Sospetto che sia per questo che il mio processo sta funzionando.

Questo funziona per te e stai producendo un bel codice pulito (presumo!). L'unica cosa che direi che devi fare è creare un cablaggio di prova in modo che altri sviluppatori possano entrare ed essere sicuri di apportare modifiche. Inoltre, il cablaggio di prova garantisce coerenza nel comportamento del codice.

Penso che il tuo approccio sia simile al mio. Di solito sono l'unico sviluppatore dei miei progetti. Ho scoperto che un apprezzamento del TDD mi ha permesso di scrivere funzioni più piccole e un codice più pulito, ma aggiungo dei test mentre scrivo il codice come cablaggio di prova. In questo modo, man mano che il codice si evolve e le funzionalità cambiano, posso essere ragionevolmente sicuro di apportare modifiche.

Un motivo secondario per scrivere i test è che ritengo che siano una forma di documentazione. Possono spiegare i miei ragionamenti alla base del motivo per cui è stata creata una funzione. Ma qui, sto pensando di più allo sviluppo guidato dal comportamento.

Il test unitario consiste nell'affrontare il problema del mantenimento del codice. Mentre ci sono persone che affermano di scrivere più velocemente codice con TDD piuttosto che senza, non mi sorprende che tu sia in grado di scrivere più nuovo codice senza scrivere test.

I problemi che posso vedere con la pratica di scrivere test appena prima di cambiarlo:

Ho spesso bisogno di apportare modifiche in fretta

Mentre potresti risparmiare tempo in generale scrivendo i test solo quando ne hai bisogno, non tutto il tempo è uguale. Trascorrere 2 ore a scrivere test per risparmiare 1 ora quando sono in modalità crisi - ne vale la pena.

È più semplice scrivere test contemporaneamente a quando scrivo il codice

Per scrivere correttamente unit test devi capire il codice che sto testando. Uso spesso i test unitari come esercizio di comprensione, ma i test unitari sul codice esistente possono richiedere molto tempo perché la comprensione del codice esistente richiede tempo. Contrastalo con la scrittura dei test mentre scrivi il codice e lo troverai molto più velocemente perché hai già capito il codice: l'hai appena scritto!

La definizione di codice legacy di Michael Feathers è codice senza test. Indipendentemente dal fatto che tu sia d'accordo con la sua definizione, è chiaro che una parte sostanziale del costo della modifica del codice esistente sta assicurando che funzioni ancora come previsto, spesso non è nemmeno chiaro quale sia il comportamento previsto.

La scrittura di test di unità compensa i costi codificando la comprensione di quale sia il comportamento corretto, oltre a fornire un modo semplice per "futuri noi" per verificare che il comportamento sia ancora corretto.

Questa è una buona domanda, e FWIW aggiungerò i miei due centesimi.

Circa un anno fa stavo codificando in Salesforce, una piattaforma che aveva un meccanismo radicato che ti costringeva a non scrivere necessariamente test prima di codificare , ma piuttosto a scrivere test in generale.

Il modo in cui ha funzionato è stato che il sistema ti avrebbe costretto a scrivere test e avrebbe fatto un calcolo del numero di righe del tuo codice che erano state testate in percentuale. Se tutto il codice in tutta l'istanza di produzione è sceso al di sotto del 75% testato. Salesforce non funziona più.

Il risultato finale è stato che ogni volta che hai fatto qualcosa in Salesforce hai dovuto scrivere o aggiornare i test. Anche se sono sicuro che questo abbia un impatto enorme sulla quota di mercato di Salesforce, in termini di vita di uno sviluppatore è stato un duro dolore per il culo .

Molte volte stavi solo cercando di ottenere un biglietto piccolo, e poi i test arrivano e raddoppiano i tempi di sviluppo, per una funzionalità che sai solo che funziona.

Quindi il concetto imbarazzante di TDD ha attraversato il nostro dipartimento, fino ai nostri database. I nostri architetti volevano effettuare test approfonditi in ogni aspetto del nostro dipartimento IT. Leggero dolore nel culo, incontra un dolore ancora maggiore nel culo.

All'epoca il TDD non aveva mai avuto senso per me, e anche adesso non lo è ancora. Molte delle funzionalità che ho scritto nel mio ruolo attuale si svolgono in un meccanismo simile a quello che hai menzionato: in sezioni verticali che perfeziono fino a quando funzionano. Quando ero in quel vecchio ruolo, e ancora adesso spesso non so cosa farà il mio codice fino a quando non lo scriverò , quindi l'idea che posso scrivere test per guidare il codice scriverò proprio. Non ha senso per me, è ingombrante e soprattutto una perdita di tempo.

Detto questo, i test sono cose meravigliose e magiche che rendono tutto giusto nel mondo . Rendono corretto il tuo codice, assicurano che la tua app faccia quello che pensi che faccia, e generalmente tutto più liscio. La domanda quindi non è se si scrivono i test prima di scrivere il codice o dopo aver scritto il codice, la domanda è: quanto tempo si impiegherà per il test. Questo è il vero problema, almeno nella mia esperienza di sviluppo software. Il test richiede tempo e denaro e devi farlo nel quadro di interessi in competizione.

E così, in generale, sono d'accordo con te: TDD in pratica è un po 'scomodo e ingombrante. A quel punto devi tenere a mente ciò che funziona meglio nella tua situazione attuale . Se stai scrivendo un codice critico, assicurati solo che sia testato in generale. Se hai tempo, prova TDD e vedi se aggiunge qualcosa al processo.

Non potrei raccomandare il tuo approccio.

Se uso il tuo approccio, ad esempio, sarebbe come il seguente (la casa è l'applicazione):

1. Comincio a costruire una casa per la mia famiglia come muratore con qualche conoscenza o come principiante.
2. Conosco requisiti come stanze per bambini, camere per gli ospiti e inizio a costruire la mia casa "prototipo".
3. Di un paio di volte dopo la tua casa "prototipo" è finita.
4. Comincio a vedere se la struttura è abbastanza stabile manualmente. Quindi raccolgo molti pesi e li porto nelle diverse stanze del primo piano. Per essere sicuro, quando mi siedo in una stanza con la mia famiglia, il soffitto non si spezza. Ma si rompe e inizio il refactoring. Prima di tutto ripulendo tutto. Quindi crearlo nuovo e testarlo di nuovo manualmente fino a quando non è abbastanza stabile.
5. Che mi trasferisco con la mia famiglia. Va tutto bene.
6. Una falena dopo, i miei cugini e i miei genitori vengono a trovarci. Ma prima che possano entrare nella nostra casa devono pagare un architetto e un ingegnere civile per assicurarsi che il soffitto non si rompa quando ci sediamo in una delle stanze del primo piano.
7. L'architetto e l'ingegnere civile hanno molto lavoro perché non hanno nulla con cui iniziare. Quindi devono andare a casa mia e guardare come la costruisco.
8. E ancora non è abbastanza stabile. Quindi devono riformattare il terreno del primo piano.
9. Ma dopo tutto va bene e tutti possono tranquillamente entrare in casa mia.

Quindi il tuo approccio costa molto tempo e molta conoscenza prima che io costruisca la casa con il tuo approccio. O ci vuole un sacco di tempo! Inoltre, non è un vero gentiluomo lasciare altri test di scrittura per il tuo codice quando i requisiti sono cambiati.

Quindi esiste un approccio migliore senza programmare un "prototipo" e che iniziare il refactoring. Invece di programmare un prototipo "fai un progetto con UML della tua applicazione come segue.

1. Creare un diagramma UseCase. Puoi usare draw.io per iniziare.
2. Quindi crea un diagramma EPK basato sui tuoi UseCases per determinare il comportamento. (COMPORTAMENTO della tua applicazione) Più veloce nel refactoring che nel refactoring di un prototipo codificato. Soprattutto quando sei un principiante.
3. Crea un diagramma di classe. (STRUTTURA della tua applicazione)
4. Determina dove potresti avere problemi nell'implementazione del comportamento.
5. Scrivi per questo un semplice prototipo con forse 10 o 20 righe di codice per determinare come implementare questo comportamento. Buono per i principianti. O guarda un tutorial, guarda il codice sorgente di altre applicazioni di esempio là fuori. Come l'hanno risolto.
6. Di iniziare a programmare. Pugno i test riusciti del tuo UseCase. Questo può essere fatto in diversi modi. Innanzitutto creare tutta la struttura necessaria per il test e quella UseCase. Quando usi Enterprise Architekt la struttura può essere generata per te. Basato sui tuoi diagrammi. Oppure crea la struttura durante il cablaggio del test. Quindi non compaiono errori di compilazione. La menzione qui è che devi solo testare il COMPORTAMENTO della tua applicazione. I casi d'uso che hai.
7. Quindi implementa il comportamento del tuo UseCase.
8. Dopo che gli UseCases riusciranno a iniziare, scrivere Test per le eccezioni. Ed è sempre bello vedere i colori verdi quando i test sono validi;)
9. E il gioco è fatto.

Sicuramente questo approccio richiede anche alcune conoscenze in UML ma è veloce da imparare. Ed è sempre più veloce rinominare una Classe o spostare le frecce in un digram che farlo nell'IDE. Ma apprendere l'uso dei framework di test sarà più estenuante all'inizio. Best è qui per guardare test di progetti open source e guardare come funzionano. Ma quando hai un'applicazione guidata dai test, la prossima applicazione sarà molto più veloce. E penso che sia bello sapere che tutto funziona bene.

Quindi voto in basso gli approcci perché richiedono molto tempo per i principianti e, dopo tutto, non vanno bene. Per avere confini netti tra la struttura e il comportamento, è possibile utilizzare la progettazione guidata dal dominio e in Disponi molto dominio con due pacchetti (un pacchetto denominato struttura e l'altro denominato comportamento). Anche per i tuoi test. esempio semplice controlla questo esempio scritto in Java.

Il codice che sto scrivendo funziona. Funziona perché lo sto testando manualmente.

Hai testato manualmente ogni possibile ramo delle tue condizioni dopo un piccolo cambiamento? Quanto tempo impiega il circuito di feedback del test manuale. Quanto vicino al loop di feedback che ottieni con i test automatizzati.

I test automatici (indipendentemente dal test o meno) ti fanno andare veloce - fornendo un ciclo di feedback più veloce sul tuo codice.

Sei sicuro di ricordarti di provare alcune condizioni manualmente dopo sei mesi - per favore non dire che documenterai tutte le condizioni importanti da testare - perché scrivere tipo di documentazione / commento equivale a scrivere test (documentazione eseguibile)

• Scegli una fetta verticale di lavoro

• Sviluppa un prototipo funzionante

• Rifattore fino a quando tutto è bello e ordinato

E ancora: mentre il refactoring hai testato manualmente tutta la logica che viene influenzata dal refactoring? Quanto tempo ci vuole per testare il cambio di refactoring? Se il refactoring rompe un po 'di codice quanto tempo impieghi a trovare un motivo per le interruzioni?

• Siediti e apprezza il bellissimo codice SOLID e testabile che ho scritto.

Il codice bello e pulito che ti è piaciuto è molto soggettivo. Il tuo codice può essere pulito e ragionevole per te. Il metodo migliore per verificare se il tuo codice è realmente leggibile, comprensibile e testabile è test e revisioni del codice effettuate da altri sviluppatori.

Hai trovato la tua strada molto produttiva solo perché sei solo uno sviluppatore che lavora con il codice e, penso, perché stai solo iniziando a lavorare in questo progetto (Quanti anni ha questo progetto a cui stai lavorando? 6-8 mesi?).
Ricordi ancora tutto ciò che hai scritto e puoi riconoscere un motivo per possibili problemi. Sono abbastanza sicuro che inizierai a scrivere test dall'inizio dopo 2-3 anni del tuo progetto, perché vuoi essere sicuro di non dimenticare nulla.

Se non commetti mai errori, non hai davvero bisogno di test. La maggior parte degli sviluppatori commette errori, ma se non lo fai mai e sei sicuro di non commettere errori in futuro (e sei l'unico sul progetto), non c'è davvero motivo di perdere tempo a scrivere test.

Ma la tua soluzione è un po 'a metà perché stai proponendo di scrivere test quando cambi codice, ma allo stesso tempo il tuo metodo presume che non commetterai mai errori quando decidi per quali parti del codice scrivere test. Funziona solo se capisci sempre perfettamente quali aree possono influenzare un cambiamento. Penso che molti sviluppatori comuni (non tu ovviamente!) Abbiano sperimentato di apportare una modifica, e quindi un test da qualche parte inaspettato fallisce, perché hai fatto un errore.

Ovviamente una buona architettura, principi SOLIDI ecc. Dovrebbero impedire che ciò accada, ma la maggior parte degli sviluppatori non è perfetta, ed è per questo che i test in tutto il sistema sono preziosi.