Sono l'unica persona del mio team che usa TDD. Come faccio a farli usarlo?
Sono seccato che quando tiro il codice di qualcuno romperà i miei test e io sono quello che deve risolverli.
L'uso delle richieste github, fork e pull risolve questo problema, in modo che sia necessario passare il test prima che il pull venga accettato?
Non sono il project manager e non riesco a convincerla a usarlo.
Per come la vedo io, l'unico modo per convincere per qualsiasi cosa sui test è dimostrare che sono utili - cioè che gli test falliti aiutano a trovare e correggere i bug .
Il modo in cui descrivi il problema, però, sembra che non sia questo il caso. Guarda ...
...when I pull, someone's code will break my tests and I am the one who has to fix them.
Se capisco correttamente, intendi che devi modificare i test. Beh, non sembra che test fallimenti aiuti a trovare e correggere bug lo fa? Se i test non aiutano a trovare bug, è una posizione piuttosto debole per iniziare a convincere i colleghi: cosa potrebbero aspettarsi di ottenere? correzioni noiose nel fragile codice di test?
Questo può sembrare un vicolo cieco, ma in realtà non lo è. Il tuo obiettivo finale (convincere per TDD) è ancora molto sensato, non lasciarlo cadere. Rifletti i tuoi sforzi per rimuovere l'ostacolo che hai scoperto.
I fallimenti dei test che ti infastidiscono ora sono essenzialmente "falsi allarmi", vale a dire che si tratta di bug nei test non presenti nel codice. Usali come un'opportunità per migliorare i test, per imparare come fare una buona progettazione di test affidabile. Lavora sui test per rendere i "falsi allarmi" meno frequenti e per rendere più facile scoprire bug reali nel codice testato.
Quando scopri bug reali, comunica ai tuoi colleghi e aiutali a risolverli e non dimenticare di indicare che questi bug sono stati rilevati dai test. Ciò renderà un terreno davvero solido per convincere i tuoi colleghi.
Vale la pena ricordare che le abilità di test design sviluppate nella fase "preliminare" saranno probabilmente necessarie di nuovo, se (quando :) finalmente convincerai i tuoi compagni di squadra a usare TDD. Pensaci ...
... Cosa succederebbe quando lo sviluppo di test guidato viene introdotto ai tuoi colleghi inesperti?
La prima cosa da aspettarsi è che i ragazzi inizieranno a scrivere test scadenti e (orrore!) a rompere anche quelli buoni mentre imparano. Per aiutarli a trovare il modo di farlo bene, avrai bisogno di una solida comprensione della buona progettazione dei test.
Tutti gli errori che trovi e risolti nei tuoi test ora, verranno ripetuti più e più volte da tutti i tuoi compagni di squadra quando inizieranno ad imparare. Se (quando!) Accade, dovresti essere pronto a spiegare in modo rapido e chiaro come migliorare se vuoi che restino positivi riguardo a TDD.
Quando volevo incoraggiare l'uso di Test Driven Development ho eseguito un Cyber-Dojo . Con questo tipo di esercizio, l'enfasi non è sul codice stesso, ma sul processo di scrivere il codice.
Abbiamo trascorso un pomeriggio, a coppie, ripetendo lo stesso kata, ma in condizioni diverse. Abbiamo iniziato con tutti i gruppi a fare un esercizio allo stesso tempo. Ciò ha fornito una base di riferimento.
Abbiamo quindi discusso alcuni dei principi di base del TDD, abbiamo tutti cambiato partner e ripetuto lo stesso kata. Abbiamo ripetuto lo stesso kata per de-enfatizzare la generazione del codice e invece concentrare le persone sul processo di denominazione dei casi di test e del ciclo Red / Green.
Poi abbiamo ripetuto di nuovo il kata, ma approssimativamente ogni 10 minuti una persona in ciascun gruppo si spostava in un altro gruppo, simulando gli ambienti di squadra piuttosto fluidi in cui ci troviamo spesso in questi giorni.
Nell'ultima versione, abbiamo scambiato entrambi partner ogni 10 minuti circa in gruppi diversi. Ciò ha contribuito a dimostrare che con TDD, anche il passaggio di consegne da una squadra a una completamente diversa non deve necessariamente essere troppo doloroso, dal momento che il progetto dovrebbe essere solo un ciclo Red / Green dal lavoro.
La cosa interessante era che c'erano poche persone che avevano fatto un TDD prima della sessione, ma quale conoscenza del TDD si diffuse rapidamente fino alla completa iterazione attraverso il kata, la maggior parte delle persone pensava in modo TDD o almeno poteva apprezzare perché potrebbe essere utile.
Le persone in generale hanno detto che il pomeriggio è stato sia divertente che informativo e ora stiamo esaminando altri modi per utilizzare il 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 la pratica deliberata di TDD e apprendere le dinamiche di squadra. Ha un sacco di 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 è che, dopo aver eseguito un kata, puoi tornare indietro e osservare la progressione rosso / verde (o forse non * 8 ') di ciascuno dei gruppi partecipanti. I semafori sono un ottimo modo per visualizzare il funzionamento del processo TDD.
Se vuoi il tuo server CyberDojo, il intero progetto può essere trovato su github e c'è anche un Chiavi in mano Linux macchina virtuale dell'appliance collegata da lì, il che significa che supponendo che tu abbia già VMware player o VirtualBox installati, puoi essere installato e funzionante entro pochi minuti dal download del apparecchio!
Se resistono a TDD, è ok. Molte persone (me compreso) stanno avendo problemi con la scrittura dei test unitari.
Tuttavia, dovresti sollevare una domanda sull'assenza di test unitari e sulla rottura dei test unitari. I test unitari sono una rete di sicurezza che previene molti possibili bug e consente il refactoring del codice. Spiega su una maggiore qualità del codice e un codice più pulito.
Penso che il meglio sarebbe trovare un video che spieghi i vantaggi dell'uso di TDD e mostrarlo in una riunione.
Se lei rifiuta di ascoltare, 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:
Se nessuna di queste funzioni funziona, potresti considerare di lavorare da qualche altra parte. Ci sono molte altre aziende in cui la tua vita sarebbe notevolmente più semplice.
Ci sono 2 problemi leggermente diversi qui: convincere le persone a fare TDD e le persone che rompono i test.
Non sono sicuro del primo problema, 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 test unitari, ma di solito trovo più efficiente scrivere il codice prima e poi i test, dal momento che mentre sto scrivendo il codice le mie idee cambiano sempre, ed è una perdita di tempo scrivere anche i test precoce (IMO).
Nel secondo numero, imposta il progetto in modo che i test unitari vengano eseguiti al momento del check-in, in modo che gli altri sviluppatori non abbiano altra scelta che sapere di aver infranto un test.
Come detto in molti altri "come dovrei convincere X ad usare il metodo / tecnologia Y", la mia risposta è sempre la stessa: per esempio.
Usalo e ottieni risultati migliori (misurabili). Quindi assicurati che gli altri lo notino.
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 indentazione.
Un sacco di buoni consigli. E ora, un po 'di più ...
Devi conquistare i cuori e le menti (WHAM) uno Luddite alla volta. Dimentica su come costringerlo giù le loro gole. Un sacco di lezioni sugli oggetti per un periodo di tempo indefinito (mi dispiace per quello). Alla fine colpirai una massa critica, convincerai le persone "giuste".
Il tuo costante e costante entusiasmo e amp; la vocazione per TDD è molto importante in una campagna WHAM.
Devi trasformare le interruzioni dei test e dei codici in momenti concreti, le lezioni che contano per i codecer. Personalizzali. OSSIA Hanno a cuore la reputazione di fornire un codice pulito superiore alla media? Si preoccupano della gestione del ragging su di loro sul codice che è ora in ritardo perché i test di integrazione hanno dato loro un controllo di realtà? Jack ha il desiderio di modificare qualche codice difficile ma ha paura degli effetti collaterali?
Raccogli buoni esempi di test-breaking come intrappolamento di bug indotti dal coder. I codificatori vedranno cambiare test come lavoro non necessario per il codice irrilevante; devono capire che i test hanno appena coperto il culo.
Trova del codice con implicazioni globali (qualche semplice metodo di utilità), costruisci alcuni test, poi dimostra che i test consentono di cambiare senza timori di terremoti in tutta l'applicazione. E intendo sottolineare il problema emotivo!
Raccogli alcuni esempi semplici di time-to-clean-code (cioè passati in produzione) e dimostra che nonostante lo sforzo extra per la codifica di test , l'abbiamo fatta fare più velocemente & con una qualità superiore.
Avviso: TDD non è una cura e non può superare la progettazione e la codifica OO errate (ma può sicuramente esporlo). Non lasciare che i luddisti incolpi lo sforzo del codice di test per la loro incompetenza.
Vorrei provare a provare di nuovo a convincere il manager. Da quello che hai scritto, non penso che potresti convincere i tuoi compagni di squadra a fare il TDD alle sue spalle.
Devi parlare la sua lingua. Il manager non si lascia impressionare dalla tecnologia, ma capisce il linguaggio commerciale:
faranno risparmiare tempo durante lo sviluppo, perché invece di test manuali (cercando di riprodurre bug localmente, giocando con la console rails ...) eseguirai test automaticamente
farà risparmiare un sacco di tempo durante la manutenzione dell'applicazione, quando puoi facilmente individuare i bug ogni volta che cambi qualcosa. Spiega che i test richiedono un investimento iniziale più elevato, ma a lungo termine si ripagheranno (il mantenimento di buoni test è solitamente rapido e semplice)
e cosa farai con i tempi supplementari? crea cose da moar e falli gemere:)
Per quanto riguarda i programmatori, prova questo argomento (ha funzionato per me, nel lontano passato): "Stai testando il codice in ogni caso, con o senza TDD .Lo lo fai manualmente invece di automatizzarlo. molte cose che possono. "
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 hai mai imparato TDD, saresti uguale a lei in questa situazione. Lo ordino.
Perché la raccolta di dati inutili non ama, apprende e vive RAII? Come hai potuto difendere la gestione automatica della memoria, ma mantenere la vecchia gestione per risorse generali come file, connessioni, ecc.? Dato che RAII è una tecnologia che non conoscono, capiscono e non hanno il tempo di usare quando hanno una scadenza che ha bisogno di lavoro.
Scommetto che non usi RAII e non sei disposto a imparare e a comprenderlo per il tuo progetto attuale. Come il tuo collega che non è disposto a imparare e capire TDD.
Leggi altre domande sui tag tdd communication ruby-on-rails