Come convincere i compagni di squadra a usare TDD [chiuso]

Sono l'unica persona nella mia squadra che usa TDD. Come faccio a farli usare?

Sono infastidito dal fatto che quando tiro, il codice di qualcuno interromperà i miei test e sono io quello che deve ripararli.

L'uso di github, fork e pull request risolverà questo problema, quindi dovranno superare il test prima di accettare il pull?

Non sono il project manager e non riesco a convincerla a usarlo.

Per come la vedo io, l'unico modo per convincere qualsiasi cosa sui test è dimostrare che sono utili, cioè che i fallimenti dei test aiutano a trovare e correggere i bug .

Il modo in cui descrivi il problema, tuttavia, sembra che questo non sia il caso qui. Guarda...

... quando tiro, il codice di qualcuno interromperà i miei test e sono io quello che deve ripararli.

Se ho capito bene, vuoi dire che devi modificare i test. Bene, non sembra che i fallimenti dei test aiutino a trovare e correggere i bug , vero? Se i test non aiutano a trovare i bug, è abbastanza debole iniziare a convincere i tuoi colleghi: cosa possono aspettarsi di ottenere? noiose correzioni nel fragile codice di prova?

Questo può sembrare un vicolo cieco, ma in realtà non lo è. Il tuo obiettivo finale (convincere per TDD) ha ancora un buon senso, non lasciarlo cadere. Concentrati nuovamente i tuoi sforzi sulla rimozione dell'ostacolo che hai scoperto.

Gli errori di test che ti danno fastidio ora sono essenzialmente "falsi allarmi", il che significa che si tratta di bug nei test non nel codice. Utilizzare questi come un'opportunità per migliorare i test, per imparare come realizzare un buon progetto di test affidabile. Lavora sui test per rendere meno frequenti i "falsi avvisi" e per facilitare la scoperta di bug reali nel codice testato.

Quando scopri veri e propri bug, fai sapere ai tuoi colleghi e aiutali a risolvere - e non dimenticare di sottolineare che questi bug vengono rilevati dai tuoi test. Ciò costituirà un terreno davvero solido per convincere i tuoi colleghi.

Vale la pena ricordare che le abilità di progettazione del test sviluppate nella fase "preliminare" saranno probabilmente necessarie di nuovo, se (quando :) alla fine convincerai i tuoi compagni di squadra a utilizzare TDD. Pensaci...

... Cosa succederebbe quando lo sviluppo test driven viene introdotto ai tuoi colleghi inesperti?

La prima cosa da aspettarsi è che i ragazzi inizieranno a scrivere test scadenti e (orrore!) Anche a rompere quelli buoni mentre imparano. Per aiutarli a trovare un modo per farlo nel modo giusto, avrai bisogno di una conoscenza abbastanza solida della buona progettazione dei test.

Tutti gli errori che trovi e correggi nei tuoi test ora, saranno ripetuti ancora e ancora da tutti i tuoi compagni di squadra quando iniziano a studiare. Se (quando!) Ciò accade, sarebbe meglio essere pronti a spiegare rapidamente e chiaramente come migliorare se si desidera che rimangano positivi riguardo al TDD.

Quando volevo incoraggiare l'uso di Test Driven Development, gestivo un Cyber-Dojo . Con questo tipo di esercizio, l'enfasi non è sul codice stesso, ma sul processo di scrittura del codice .

Abbiamo trascorso un pomeriggio, in coppia, ripetendo lo stesso kata, ma in condizioni diverse. Abbiamo iniziato con tutti i gruppi che facevano un esercizio contemporaneamente. Ciò ha fornito una base.

Abbiamo quindi discusso alcuni dei principi di base del TDD, facendo cambiare a tutti i partner e ripetere lo stesso kata. Abbiamo ripetuto gli stessi kata per de-enfatizzare la generazione del codice e concentrare invece le persone sul processo di denominazione dei casi di test e sul ciclo Rosso / Verde.

Quindi abbiamo ripetuto nuovamente i kata, ma all'incirca ogni 10 minuti una persona in ciascun gruppo si spostava in un altro gruppo, simulando gli ambienti di squadra piuttosto fluidi che spesso ci troviamo in questi giorni.

Nell'iterazione finale, abbiamo fatto cambiare entrambi i partner ogni 10 minuti circa in gruppi diversi. Ciò ha contribuito a dimostrare che con TDD, anche il passaggio da una squadra a una squadra completamente diversa non deve necessariamente essere troppo doloroso, poiché il progetto dovrebbe essere solo un ciclo rosso / verde dal lavoro.

La cosa interessante era che c'erano poche persone che avevano fatto qualsiasi TDD prima della sessione, ma che conoscenza TDD ci fosse rapidamente diffusa fino all'iterazione finale attraverso i kata, la maggior parte delle persone pensava in modo TDD o almeno poteva apprezzare il perché potrebbe essere utile.

La gente generalmente diceva che il pomeriggio era sia divertente che informativo e ora stiamo cercando altri modi per usare Cyber-Dojo sul mio posto di lavoro.

Cyber-Dojo , scritto da Jon Jagger , funziona incredibilmente bene per questo tipo di esercizio. È un ambiente integrato basato sul web per fare pratica deliberata di TDD e conoscere le dinamiche del team. Ha molti kata selezionati appositamente per aiutare le persone a concentrarsi sul processo di TDD e non sul problema. Supporta anche una vasta gamma di lingue, da Python e Ruby a Java e C ++.

La cosa migliore è, dopo aver fatto un kata, puoi tornare indietro e guardare la progressione rosso / verde (o forse non * 8 ') di ciascuno dei gruppi partecipanti. I suoi semafori sono un ottimo modo per visualizzare come funziona il processo TDD.

Se vuoi il tuo server CyberDojo, l' intero progetto può essere trovato su github e c'è anche una macchina virtuale Linux chiavi in ​​mano collegata da lì, il che significa che supponendo che tu abbia già installato VMware player o VirtualBox , puoi essere attivo e funzionante all'interno pochi minuti per scaricare l'appliance!

Se resistono al TDD, va bene. Molte persone (incluso me stesso) hanno problemi a scrivere prima i test unitari.

Tuttavia, dovresti sollevare una domanda sull'assenza di test unitari e sull'interruzione dei test unitari. I test unitari sono una rete di sicurezza che impedisce molti possibili bug e consente il refactoring del codice. Spiega sulla qualità del codice più elevata e sul codice più pulito.

Penso che il migliore sarebbe trovare un video che spieghi i vantaggi dell'utilizzo di TDD e mostrarlo durante una riunione.

Se rifiuta di ascoltare, allora puoi provare ad andare da qualcuno sopra di lei, ma potrebbe non essere molto intelligente se il tuo capo è così testardo.

È davvero difficile convincere le persone a cambiare le loro abitudini, ma qui ci sono alcune cose che puoi provare:

• Parla con gli altri sviluppatori e spiega loro perché pensi che TDD sia una buona idea.
• Convincili (o almeno alcuni di loro) a provarlo per un tempo limitato
• Cerca di stabilire alcuni requisiti minimi per lavorare bene come una squadra. Non devono necessariamente fare TDD, ma certamente non dovrebbero controllare il codice che non supera i test unitari. Questo è un problema separato rispetto a convincerli ad usare TDD, ed è molto più importante da affrontare.
• Cerca di convincere il management a imporre un periodo di prova per TDD. Dovrai essere pronto a fornire alcune prove sul perché questa è una buona pratica e su come farà risparmiare tempo e denaro all'azienda in futuro.

Se nulla di tutto questo funziona, potresti prendere in considerazione l'idea di lavorare altrove. Ci sono molte altre aziende in cui la tua vita sarebbe notevolmente più facile.

Ci sono 2 problemi leggermente diversi qui: convincere le persone a fare TDD e le persone a superare i test.

Non sono sicuro del primo numero, personalmente lo trovo un modo artificiale di lavorare e non adatto a tutti i tipi di sviluppo. Sono tutto per avere una buona suite di unit test, ma di solito trovo più efficiente scrivere prima il codice e poi i test, poiché mentre scrivo il codice le mie idee cambiano sempre, ed è una perdita di tempo anche scrivere test presto (IMO).

Sul secondo problema, imposta il progetto in modo che i test unitari vengano eseguiti al momento del check-in, in modo che altri sviluppatori non abbiano altra scelta che sapere di aver superato un test.

Come detto in molti altri "come dovrei convincere X ad usare il metodo / la tecnologia Y", la mia risposta è sempre la stessa: per esempio.

Usalo e ottieni risultati migliori (misurabili). Quindi assicurati che gli altri se ne accorgano.

Su un progetto esistente, non lo fai. È come se dovessi apportare modifiche al modo in cui le parentesi graffe vengono inserite nel codice legacy perché non ti piace lo stile di rientro.

Un sacco di buoni consigli. E ora, un po 'di più ...

Devi vincere cuori e menti (WHAM) un Luddite alla volta. Dimentica di forzarlo in gola. Molte lezioni oggettive per un periodo di tempo indefinito (mi dispiace per quello). Alla fine colpirai una massa critica, convincerai le persone "giuste".

Il tuo costante e coerente entusiasmo e vocazione per TDD è molto importante in una campagna WHAM.

Devi trasformare le interruzioni del test e le modifiche al codice in momenti insegnabili, le lezioni che contano per i tuoi codificatori. Renderlo personale. IE Si preoccupano della reputazione di fornire un codice pulito superiore alla media? Si preoccupano della gestione da parte loro del codice che ora è in ritardo perché i tester di integrazione hanno dato loro un controllo della realtà? Jack ha il desiderio di modificare alcuni codici difficili ma ha paura degli effetti collaterali?

Raccogli buoni esempi di interruzione del test come intrappolamento di bug indotti dal programmatore. I programmatori vedranno cambiare i test come un lavoro inutile per codice irrilevante; devono capire che i test hanno appena coperto il culo.

Trova del codice con implicazioni globali (qualche semplice metodo di utilità), crea alcuni test, quindi dimostra che i test consentono il cambiamento senza paura dei terremoti durante l'applicazione. E intendo anche sottolineare il problema emotivo!

Raccogli alcuni semplici esempi di time-to-clean-code (ovvero passati alla produzione) e dimostra che, nonostante lo sforzo supplementare per la codifica dei test , l'abbiamo eseguita più velocemente e con una qualità superiore.

Avvertenza: TDD non è una cura per e non può superare la cattiva progettazione e codifica OO (ma sicuramente può esporla). Non lasciare che i luddisti incolpino lo sforzo del codice di prova per la loro incompetenza.

Proverei di nuovo a convincere il manager. Da quello che hai scritto, non credo che potresti convincere i tuoi compagni di squadra a fare TDD alle sue spalle.

Devi parlare la sua lingua. I manager tendono a non essere colpiti dalla tecnologia, ma comprendono il linguaggio aziendale:

• i test risparmieranno tempo durante lo sviluppo, perché invece di test manuali (cercando di riprodurre bug localmente, giocando con la console di rotaie ...) eseguirai test automaticamente

• test farà risparmiare molto tempo durante la manutenzione dell'applicazione, quando puoi facilmente rilevare bug ogni volta che cambi qualcosa. Spiega che i test richiedono un investimento iniziale più elevato, ma si ripagheranno da soli a lungo termine (la manutenzione di buoni test è in genere semplice e veloce)

• e cosa farai con il tempo extra? creare roba di ruggito e farli gemere soldi :)

Per quanto riguarda i programmatori, prova questo argomento (ha funzionato per me, molto tempo fa): "Stai testando il codice comunque, con o senza TDD. Solo tu lo fai manualmente invece di automatizzarlo. Gli sviluppatori intelligenti automatizzano il maggior numero di cose possibile. "

Su progetti reali con scadenze le persone vogliono concentrarsi sul portare a termine il lavoro con ciò che sanno. Questa è solo la natura umana. E se non avessi mai imparato TDD, saresti la stessa di lei in questa situazione. Lo garantisco.

Perché la folla della raccolta dei rifiuti non ama, impara e vive RAII? Come hai potuto sostenere la gestione automatica della memoria ma attenersi alla vecchia gestione per risorse generali come file, connessioni, ecc.? Perché RAII è una tecnologia che non conoscono, comprendono e non hanno tempo di usare quando hanno una scadenza che richiede lavoro.

Scommetto che non usi RAII e non sei disposto a impararlo e capirlo per il tuo progetto attuale. Lo stesso del tuo collega che non è disposto a imparare e capire TDD.