Come motivare i colleghi a scrivere unit test? [chiuso]

Stiamo lavorando su un prodotto di grandi dimensioni che è in produzione da circa 5 anni. La base di codice sta funzionando. Non proprio bene ma funziona. Le nuove funzionalità vengono lanciate in produzione e testate con un piccolo QA. I bug sono stati corretti, ecc. Ma nessuno, tranne me, sta scrivendo test unitari. Nessuno usa il potere di "rintracciare" i bug scrivendo unit test per assicurarsi che questo speciale bug (test case) non si verifichi mai più.

Ho parlato con la direzione. Ho parlato con gli sviluppatori. Ho parlato con tutti in tutta l'azienda. Tutti dicono: "Sì, dobbiamo scrivere più unit test!" È successo circa un anno fa. Da allora ho forzato l'introduzione della revisione del codice pre-commit ( Gerrit ) e l'integrazione continua ( Jenkins ).

Ho tenuto alcune riunioni sui test unitari e ho anche mostrato i vantaggi della stesura dei test unitari. Ma nessuno sembra essere interessato.

Q1: Come motivare i miei colleghi a scrivere unit-test?

Q2: Come posso rimanere motivato a seguire i miei standard di qualità del codice personale? (A volte è davvero frustrante!)

PS: Alcuni fatti frustranti (raggiunti in 1 anno):

• Prove unitarie totali: 1693
• Totale "test unitari di esempio": circa 50
• Fatto da me: 1521

Modifica: mi aspetto troppo? È il mio primo posto di lavoro e sto cercando di fare del mio meglio.

Modifica 2: Sulla base di tutte le risposte ho creato una piccola lista di controllo per me stesso. Ho parlato con due sviluppatori in privato e abbiamo parlato bene e onestamente.

Uno di loro mi ha detto, come ha detto Telastyn , che è davvero a disagio con i test unitari. Ha detto che vorrebbe essere "più professionale" ma ha bisogno di un calcio d'inizio. Ha anche detto che il nostro incontro di unit test con tutti gli sviluppatori (intorno all'11 settembre) è stato positivo, ma era troppo affollato. Meh. Alcuni critici per me, ma imparerò da quello. (vedi le risposte sotto relative alle riunioni di tdd kata!)

L'altro ha affermato di non essere interessato a scrivere unit test. Pensa che il suo lavoro sia abbastanza buono per il suo stipendio. Non vuole fare più sforzi. Ero abbastanza senza parole. Tipico "lavoratore" 9-5.

La prossima settimana parlerò con gli altri sviluppatori.

Grazie per le tue fantastiche risposte (finora!) E per il tuo supporto. Lo apprezzo molto! Ho imparato molto, grazie mille!

Ho notato che parlare di TDD difficilmente funziona. Alla gente piace vedere risultati grezzi . Dire che "scrivere test ridurrà i tempi di sviluppo" è probabilmente vero, ma potrebbe non essere sufficiente per convincere qualcuno.

Ero in una posizione simile (beh, non male come la tua), e si è risolto da solo quando le persone hanno iniziato a lavorare sul mio codice (nota: il mio codice era unit test, gli altri non così tanto). Quando qualcosa ha smesso di funzionare, il follow-up naturale dopo l'indagine locale è stato quello di chiedermi quale potrebbe essere la ragione . Quindi ci siamo seduti, abbiamo eseguito i test unitari e visto cosa è successo. Se i test passavano, la maggior parte delle volte i problemi erano nel nuovo codice non testato. In caso contrario, i test erano in genere in grado di individuare il problema (o almeno indicarci la giusta direzione). Abbiamo corretto il bug, i test erano di nuovo attivi, tutti erano felici.

Per farla breve, sono emerse alcune situazioni come questa e altri 2 sviluppatori sono diventati appassionati di TDD / test (ce ne sono ancora altri da fare, ma sembra promettente).

Per quanto riguarda i consigli, puoi provare con TDD kata; semplice compito da implementare utilizzando un primo approccio di test anziché nessun test . A seconda della complessità dell'attività, l'approccio non test dovrebbe in genere essere più lento, soprattutto con modifiche incrementali richieste:

• Il calcolatore di stringhe di Roy
• Bank OCR

Modifica : il commento di OP mi ha fatto capire che c'è ancora un argomento più forte a sua disposizione: la regressione o la restituzione di bug . Questo tipo di situazioni sono esempi perfetti che dimostrano quanto possano essere utili i test unitari. Alle persone piacciono i numeri - come ho detto, dire che "il test unitario è buono" potrebbe non essere convincente, ma organizzare i dati come di seguito potrebbe sicuramente essere:

• tempo impiegato per implementare funzionalità (non sono stati scritti test; presumo che ciò sia accaduto spesso, quindi dovrebbe essere relativamente facile trovare un esempio del genere)
• tempo stimato per implementare la funzione con TDD (o anche test dopo l' approccio; non importa - l'importante è la presenza di unit test)
• tempo impiegato per risolvere il bug su codice non testato vs testato

Una cosa di cui avvertirti (questa migth è ovvia ma vale la pena notare): bias sui risultati - assicurati di non selezionare l'esempio in cui l'unico modo per individuare un bug con test era scrivere test per quel bug. Di solito, nessuno sa che il bug si verificherà in anticipo, ma è allettante dire "amico questo bug sarebbe banale se avessimo test per X" - è facile trovare una tattica vincente per una guerra dopo che è finita.

Il risultato di questi esempi dovrebbe essere una semplice domanda: se potessi dedicare x-ore allo sviluppo della funzione Y, perché dovresti insistere nel farlo in 2x ?

Per prima cosa devi sapere perché non stanno scrivendo test.

La pianificazione è spesso limitata, ma dici di non averlo.

Il prossimo motivo è che con una grande base di codice non testata esistente, scrivere test probabilmente sembra schiacciante, un lavoro senza fine (come il bucato e altrettanto eccitante). Quindi la natura umana è pensare che sia troppo da affrontare, quindi la salterò.

Un altro motivo potrebbe essere che mentre pensano che i test siano una buona idea, non sono sicuri di come iniziare a scriverli soprattutto se non hanno mai lavorato da nessuna parte che li abbia scritti.

Un'altra forte possibilità è perché in realtà non vedono alcun valore per più lavoro, anche se stanno dando un grande servizio all'idea.

Quindi, come gestite le diverse ragioni?

Il motivo è semplice, mostra loro un esempio di come consente di risparmiare tempo di sviluppo.

Motivo due: mostra loro quanti test hai scritto in un anno e quale percentuale della base di codice copre. Fai i calcoli per mostrare quanti più test potrebbero avere in questo momento l'anno prossimo se lo fanno. Una volta che vedono che piccoli passi avanti su base giornaliera si sommano davvero, l'intera idea non è così travolgente. Se riesci a estrarre i dati dal sistema, mostra loro quanti bug erano bug ripetuti nelle parti non testate del codice e quanti bug ripetitivi compaiono nel codice con unit test.

Il motivo 3 è l'allenamento, non solo la dimostrazione. Fagli scrivere test in un corso di formazione.

Motivo 4, questo è il nocciolo della questione. Innanzitutto, scegli un punto dolente, uno di quei bug che è tornato più volte. Quando arriva, questo è il momento di suggerire al management che se avessero avuto dei test unitari su questo oggetto, non sarebbe più tornato indietro come un penny cattivo.

Un altro modo per affrontare il motivo 4 è far sì che la gestione lo faccia parte del processo e il codice non passa la revisione del codice a meno che i test non superino anche la revisione del codice. Meglio avvicinarli con questo facendo una politica subito dopo uno di quei punti dolenti o preferibilmente subito dopo averne avuto diversi nel giro di pochi giorni.

A tutti noi piace pensare che come sviluppatori ci autogestiamo (LOL), ma gli ambiziosi si preoccuperanno di ciò che la gestione sottolinea loro di cui dovrebbero preoccuparsi e i professionisti che si autogestiscono davvero stanno già scrivendo i test. Se non si preoccupano né di essere professionali e di fare le migliori pratiche perché migliorano il prodotto o di come impressionare i manager per essere promossi (o non licenziati), allora potresti considerare se questo è il posto giusto per te. Se non riesci a far sì che il management si preoccupi delle migliori pratiche, allora combatterai una battaglia in salita fino in fondo, potresti valutare se questa è la cultura aziendale giusta per te. Mentre ogni posto di lavoro ha i suoi problemi (e scappare non è sempre la risposta), questo posto non sembra adattarsi al tuo livello di professionalità.

Vorrei iniziare dimostrando i benefici del TDD. Prova a mostrare i vantaggi del test unitario.

Come normali esseri umani, gli sviluppatori sono motivati ​​da benefici. Non vogliono fare cose che creano solo più lavoro. Test unitari significa meno lavoro . Significa uscire di più con gli amici. Significa divertirsi di più perché non devi passare tutte le sere a programmare fino alle 23:00. Significa andare in vacanza di più con la massima tranquillità.

Uno dei più grandi vantaggi di TDD è che si può refactoring il programma per una migliore progettazione o semplicemente cambiare il nome di qualcosa ... e finchè che il design non si rompe i test, si può avere fiducia al 100% che la modifica non ha rotto nulla.

Un altro ottimo caso per TDD è la creazione di unit test per il codice legacy . Ciò rappresenterebbe uno dei modi migliori per iniziare a rimediare al male. A lungo termine, ciò servirà a migliorare la tua conoscenza della base di codice, a comprenderne i punti di forza e di difetto, individuare la logica di business codificata nel codice e darti un buon inizio per migliorare la qualità andando avanti!

Buoni riferimenti per ulteriori letture:

• Perché dovresti scrivere test unitari
• Visibilità della motivazione e unit test
• L'arte del test unitario, secondo Roy Osherove

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

Penso di aver aggiunto un segnalibro a quel link da un articolo di Jeff Atwood qualche tempo fa [modifica: sì, eccolo] . Vecchio ma rilevante. A causa di questi benefici e di altri che saranno sicuramente indicati in altre risposte, i tuoi programmatori dovrebbero essere in grado di motivare se stessi ! Ciò consentirà loro di lavorare in modo più efficiente e quindi rendere il loro lavoro un po 'più semplice. Chi non lo vuole?

Per quanto riguarda la tua seconda domanda: il tuo senso di proprietà e l'orgoglio per gli standard di qualità del codice dovrebbero farti andare avanti con loro . Pensa a ciò che vuoi ottenere avendo tali standard e chi ne trae beneficio. Anche i miei standard di codice personale possono essere frustranti, ma mi sento sempre come se stessi facendo un favore al mondo / azienda / squadra implementandoli. Quindi non penso che tu stia cercando di fare troppo - i risultati varieranno da un posto all'altro, ma almeno stai facendo lo sforzo.

Questo sembra un grande caso di esempio .

Ci sono due aspetti inerenti alla natura umana che stai combattendo:

• Alle persone creative non piace il processo.
• Alla maggior parte delle persone non piacciono i giudizi negativi esterni sulla loro qualità.

È molto difficile combattere questo con lezioni, dichiarazioni di gestione o persino logica. Devi vincere sfruttando un aspetto alternativo della natura umana.

• Le persone imitano il comportamento dei migliori dipendenti

Se i migliori dipendenti usano TDD e funziona, il processo si espanderà. Se non lo fanno, non lo farà. Se devi convincere qualcuno, sono i primi 1 o 2 dipendenti.

Chiediglielo.

Dici che le persone sono state informate e accetti che dovrebbero scrivere altri test. Perché non lo sono?

Potrebbe non (spesso non lo è) una questione di semplice motivazione. Potrebbero dimenticarsene. Potrebbero sentirsi sotto la pressione del tempo. Potrebbero non sapere come scrivere buoni test. Potrebbero pensare che sei così bravo da non aver bisogno di farlo. Conoscere la causa principale ti aiuterà a risolvere meglio il problema.

Penseresti che i test unitari sarebbero la vendita stessa. Non so come funzioni la tua azienda, ma quando si verifica un problema durante un'implementazione della produzione, la lavoriamo fino a quando non viene risolta. Non importa se succede alle 2:00 di domenica mattina. Questo è molto raro per noi, ma quando lo fa, fa schifo.

Vorrei iniziare chiedendo loro quante volte hanno dovuto alzarsi nel cuore della notte per risolvere alcuni importanti problemi che avrebbero potuto facilmente essere trovati test automatici. Ciò non significa che i test automatizzati risolveranno tutto, ma dovrebbero contribuire a ridurlo.

Il secondo grande venditore è il ciclo di controllo qualità. Prima dell'inizio del TDD nella mia azienda, spingevamo le nuove versioni al QA per testarle ogni settimana. Avrebbero creato un mucchio di bug da quella versione, risolto quei bug e ne avremmo spinto un altro. Ripeti fino al termine. Il primo progetto che abbiamo realizzato TDD non ha richiesto un push out al QA fino a diverse settimane dopo. E il numero di bug trovati è stato molto, molto piccolo. 10% rispetto a un progetto simile. Hai comunque modo di compilare quelle statistiche per la tua squadra?

L'altro grande punto di forza è stato il modo in cui il codice si è occupato del TDD, è stato più facile da leggere, perché volevamo rendere più semplice il test. Mostra un confronto tra il codice scritto per unit test e il codice non scritto.

Infine, mostra loro come saranno in grado di refactificare il codice con sicurezza.

Tieni a mente tutto ciò quando non hai voglia di scrivere test. :)

Vorrei ampliare la risposta di HLGEM , in particolare questa sezione:

Il prossimo motivo è che con una grande base di codice non testata esistente, scrivere test probabilmente sembra schiacciante, un lavoro senza fine (come il bucato e altrettanto eccitante). Quindi la natura umana è pensare che sia troppo da affrontare, quindi la salterò.

Ho scoperto che il codice che scrivo con l'intenzione di scrivere test è un codice significativamente migliore del codice che scrivo senza l'intenzione di scrivere test; chiedendomi Come testerò questa funzione? impone una migliore progettazione di ogni singola funzione. (Minore dipendenza dai dati globali o semi-globali; IO separato dal calcolo; le funzioni fanno solo una cosa; gestione coerente degli errori; e così via.)

Cercare di mettere test su un vecchio codice che non è stato scritto pensando ai test potrebbe essere oltremodo frustrante.

Ho usato alcune tecniche:

a) impostare una build automatizzata. Quando qualcuno rompe qualcosa che hai testato, mostra loro come il test lo ha rilevato e quanto grave sarebbe stato il bug.

b) Realizza progetti complessi con test (guidi). Questo mostrerà quanti bug esistono in quel progetto. Ho avuto un progetto di interazione server complesso che ha iniziato a funzionare in modo impeccabile. Non ha mai fallito il controllo qualità e tutti i test di integrazione sono stati eseguiti senza problemi al 100%. Tale sistema divenne noto come altamente stabile e la gestione generale ne fu contenta. Quello che fai in queste situazioni è presente come lo ha permesso il test unitario.

c) Tirare una persona alla volta. Colui che ti ascolta. Affronta i bug e mostra come i test espongono problemi profondi e difficili. Questo aiuta. Non è mai una cosa facile. Ma una volta che avrai un fan, ti aiuterà solo. È un effetto domino.

Eseguire il test dell'unità di misura nel processo. Se un bug mostra in produzione che è troppo ovvio per essere colto nel test unitario, allora questo tizio si prende la colpa. Assegna alle persone di scrivere ogni test che fanno. Scegli casualmente i casi e osserva l'esecuzione di alcuni casi ogni settimana. Effettuando unit test, le persone chiederanno i requisiti e alla fine legheranno i requisiti allo sviluppo e, si spera, svilupperanno software che sia richiesto e funzionante :)