Come trattare con quelle persone che rompono TDD?

Question

Personalmente preferisco davvero i Test unitari e li scrivo per una copertura "buona". (diciamo che cerco il più possibile di scrivere buoni test;)

Come al solito qualche tempo dopo qualcuno ha bisogno di aggiungere alcune funzionalità al codice (aggiungere metodi alle classi e così via). Egli non infrange quei test unitari scritti ma si rifiuta di scrivere ulteriori (che riguarderebbero quelle caratteristiche aggiuntive del codice che ha scritto). Questo porta a un grosso buco nel processo di tdd (e forse peggio ancora un effetto finestra rotto)

tutto ciò che posso fare per fargli scrivere quei test? come gestisci queste persone?

Answer 1

Ricordare che il TDD non riguarda principalmente la generazione di una buona copertura del test unitario; si tratta di motivare il con un buon design, in primo luogo, assicurandosi che il codice che si scrive esegua ciò che ci si aspetta in secondo luogo, e di fornire un corpo di test di alta qualità terzo.

Quando un altro programmatore estende una classe senza scrivere test, perde questi vantaggi e dovresti provare pena per loro. Ma quando lavori, continuerai a lavorare nel modo migliore che sai (test prima) perché sai che il codice è disaccoppiato, che è facile per il consumatore e che il tuo codice fa quello che ti aspetti.

Il più grande dolore per te è che devi stare attento a ciò che si refactoring: se si esegue il refactoring del codice che è sotto test, si può andare veloce, e la progettazione migliorerà rapidamente e in modo sicuro. Se stai effettuando il refactoring del codice che non è stato testato, dovresti essere estremamente cauto sul refactoring (magari solo usando strumenti automatici affidabili per farlo) o aggiungere i test.

Alla fine, continuerai a beneficiare del tuo uso di TDD, perché produci codice più chiaro e corretto, più veloce, mentre il tuo collega con problemi di TDD ne soffrirà.

Answer 2

A parte una politica aziendale e le ripercussioni del proprio manager, non c'è molto che si possa fare a riguardo. Forse c'è qualche modo nel tuo strumento di controllo del codice sorgente per richiedere che qualsiasi cosa pubblica abbia un test unitario contrassegnato come tale.

Si potrebbe anche scrivere una macro che fa parte del processo di compilazione che cerca qualsiasi cosa contrassegnata PUBLIC (io sono un VB guy), quindi controlla che, da qualche parte nella soluzione, ci sia un test unitario con un codice commento che lo collega sufficientemente. Se non si ha un test unitario associato, si interrompe la compilazione e si invia una e-mail all'intero gruppo di sviluppo che blandisce a sufficienza detto non tester.

Forse sarò set che qui, ora che ci penso ...

Answer 3

Se si dispone di un processo di compilazione è possibile utilizzare uno strumento come NCover o PartCover e non riuscire la costruzione se la copertura isn' t sufficiente

Answer 4

Copertura del codice di traccia con alcuni strumenti, ad es. per Java c'è Emma e generare un report per la gestione con ogni versione. Quando i numeri sono troppo bassi o la gestione del down dovrebbe indagare sulle cause.

Answer 5

Programmazione coppie. Con due persone che lavorano su qualcosa, i programmatori hanno meno probabilità di prendere scorciatoie come questo.

Answer 6

Riproduci il video di "Do not tase me bro!" ragazzo come avvertimento

Answer 7

Non avvicinarti a questo come un confronto!Stai chiedendo come forzare un collega a fare qualcosa a cui chiaramente non vede alcun beneficio. Non puoi far usare a qualcuno TDD, come hai già visto tu stesso. L'unico modo in cui uno sviluppatore abbraccerà TDD è quando qualcun altro li aiuta a raggiungere quel "aha!" momento. Sii rispettoso come un collega a un altro e mostralo attraverso le tue azioni ed essere positivo nel volere aiutarlo a superare la gobba mentale.

Answer 8

Insegna ai tuoi colleghi come fare il TDD, in modo che possano capovolgere il cervello (ho avuto quella sensazione quando ho provato TDD la prima volta) e ho iniziato a scrivere i test per primi.

Una volta ho fatto un esperimento con un mio amico programmatore, che non conosceva TDD. Sono venuto a casa sua e abbiamo iniziato a scrivere Tetris usando TDD (abbiamo trascorso circa 6 ore quel giorno e abbiamo progredito bene). Per prima cosa ho scritto un metodo di prova, e poi ha scritto il codice per superare il test. All'inizio era un po 'contrario a scrivere "la cosa più semplice che potesse funzionare" (come ad esempio codificare i valori di ritorno nei primi banali test) e non pianificare molto in anticipo, ma in ogni caso lo ha risucchiato e ha seguito le mie istruzioni. Mentre progredivamo, sembra che lentamente cominciò a capire qual era il punto in tutto questo.

Answer 9

Dare all'esempio. Il tuo collega potrebbe semplicemente non capire come usare TDD in modo appropriato. La prossima volta che succede, scrivi un test unitario per loro. Assicurati di segnalarlo a loro: "Ehi, ho notato che hai aggiunto la funzione x al programma senza un test di unità, quindi ne ho scritto uno per te e lo metto qui." In questo modo hanno un esempio e non si sentiranno in imbarazzo a dover chiedere come test unitario.

Eseguire questa operazione solo una o due volte. Successivamente, assicurati di menzionare eventuali eventi futuri. Sareste sorpresi della differenza educatamente: "Ehi, non hai scritto un test unitario per la funzione y, mi aiuterebbe davvero se ne scrivessi uno per me". Ricorda, l'obiettivo non è quello di provare facendo test di scrittura. È rendere i test di scrittura meno complicati di quelli che non si scrivono i test.

Se quanto sopra non funziona, è il momento di una discussione con la direzione. Hai già provato a risolvere la situazione amichevolmente, quindi è tempo di considerare un approccio meno che amichevole.