Come si mantiene la disciplina quando si fa TDD?

Question

Quando sono entusiasta di una nuova funzione che sto per implementare o di un bug che ho appena "compreso", c'è l'urgenza di saltare nel codice e ottenere l'hacking. Ci vuole un certo sforzo per impedirmi di farlo e scrivere prima il test corrispondente. Più tardi il test si rivela spesso banale 4-liner, ma prima di scriverlo c'è ancora il pensiero dietro la testa, "forse posso saltare questo, questa volta?" Idealmente mi piacerebbe avere voglia di scrivere test, e solo allora, forse, il codice :)

Quale metodo (o modo di pensare o trucco mentale o politica di auto-ricompensa o qualsiasi altra cosa) usi per aiutare mantenere la disciplina? O lo pratichi solo finché non ti sembra naturale?

Answer 1

Mi piace il feedback immediato del test, è una ricompensa sufficiente per me. Se riesco a riprodurre un bug in un test che è un buon feeling, so che sono diretto nella giusta direzione, invece di indovinare e possibilmente perdere tempo.

Mi piace lavorare in Test-First perché mi sembra che mi tenga più in sintonia con ciò che il codice sta facendo in realtà anziché supporre basato su un modello mentale possibilmente inaccurato. Essere in grado di confermare le mie ipotesi in modo iterativo è un grosso guadagno per me.

Answer 2

wear a green wristband

Answer 3

1) È coppia con qualcun altro nella tua squadra. Una persona scrive il test, gli altri strumenti.

Si chiama "ping-pong".

Fare questo ti costringerà a discutere di design e capire cosa fare.

Avere questa discussione rende anche più facile vedere quali test avrete bisogno.

2) Quando lavoro per conto mio, mi piace provare pezzi di codice in modo interattivo. Li digito solo al prompt rubino. Quando sto sperimentando in questo modo, spesso ho bisogno di impostare alcuni dati per sperimentare e alcune istruzioni di stampa per vedere quale sia il risultato.

Questi piccoli, indipendenti esperimenti usa e getta sono di solito:

• un modo rapido per stabilire la fattibilità di un'implementazione, e
• buon punto di partenza formalizzare in un test.

Answer 4

Trovo che i test di scrittura mi aiutano a delineare il mio approccio al problema in questione. Spesso, se non riesci a scrivere un buon test, significa che non hai necessariamente pensato abbastanza a quello che dovresti fare. La soddisfazione di essere fiducioso di sapere come affrontare il problema una volta che i test sono stati scritti è piuttosto utile.

Answer 5

Ti farò sapere quando trovo un metodo che funziona. :-)

Ma seriamente, penso che il tuo commento "pratica fino a che non si sente naturale" colpisce quasi l'unghia sulla testa. Un test in 4 righe può sembrare banale, ma finché ciò che si sta testando rappresenta un vero punto di fallimento, allora vale la pena farlo.

Una cosa che ho trovato utile è includere la convalida della copertura del codice come parte del processo di compilazione. Se non riesco a scrivere dei test, la build si lamenterà con me.Se continuo a non riuscire a scrivere dei test, la configurazione di integrazione continua verrà "cancellata" e tutti coloro che si trovano nelle vicinanze sentiranno il suono che ho collegato alla notifica "broken build". Dopo alcune settimane di "Buon dolore ... Hai rotto di nuovo?", E commenti simili, ho presto iniziato a scrivere altri test per evitare l'imbarazzo.

Un'altra cosa (che mi è venuta in mente solo dopo aver inviato la risposta la prima volta) è che una volta ho preso l'abitudine di scrivere i test per primi, ho ottenuto un rinforzo positivo dal fatto che potevo fornire bug - correzioni e funzionalità aggiuntive con una fiducia molto maggiore di quella che potevo nei miei giorni di test pre-automatizzati.

Answer 6

Penso che la parte importante di tenere sotto controllo fino a TDD è di avere il progetto di test impostato correttamente. In questo modo aggiungere un banale test case è davvero banale.

Se per aggiungere un test è necessario prima creare un progetto di test, quindi capire come isolare i componenti, quando prendere in giro cose, ecc. Ecc. Cade nel cestino troppo duro.

Quindi penso che ritorni ad avere i test di unità completamente integrati nel processo di sviluppo.

Answer 7

Quando ho iniziato a fare TDD intorno al 2000, mi sono sentito molto innaturale. Poi è arrivata la prima versione di .net e la porta JUnit di NUnit, e ho iniziato a praticare TDD al livello Shu (di Shu-Ha-Ri), il che significava testare (prima) tutto, con le stesse domande del tuo.

Pochi anni dopo, in un altro luogo di lavoro, insieme a uno sviluppatore senior molto competente e competente, abbiamo intrapreso i passi necessari per raggiungere il livello Ha. Ciò significava, ad esempio, che il report sulla copertura non fosse ciecamente protagonista, ma la domanda "è davvero utile per questo tipo di test e aggiunge più valore di quanto costi?".

Ora, in un altro luogo di lavoro, insieme a un altro grande collega, sento che stiamo facendo i primi passi verso il livello Ri. Per noi ciò significa attualmente un grande interesse per le storie BDD/eseguibili. Con quelli che stanno verificando i requisiti a un livello superiore, mi sento più produttivo, dal momento che non ho bisogno di (ri) scrivere una serie di test unitari ogni volta che un'interfaccia pubblica di classe deve cambiare, sostituire una chiamata statica con un metodo di estensione e così via.

Non fraintendetemi, i soliti test di classe TDD vengono ancora utilizzati e rappresentano un grande valore per noi. È difficile esprimere a parole, ma siamo semplicemente molto più bravi nel "sentire" e "percepire" quali test hanno senso e come progettare il nostro software, di quanto non ne fossi capace dieci anni fa.

Answer 8

Il modo più semplice che ho trovato è usare TDD molto. Ad un certo punto, scrivere codice senza test unitari diventa un'attività molto, molto nervosa.

Inoltre, provare a concentrarsi sull'interazione o sul test comportamentale piuttosto che sui test basati sullo stato.