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

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

Ero in posizione simile (beh, non male come il tuo), e si è risolto da solo quando le persone hanno iniziato a lavorare sul mio codice (nota: il mio codice è stato testato unitamente, altri non così tanto). Quando qualcosa ha smesso di funzionare, il follow-up naturale dopo le indagini locali è stato quello di chiedermi quale potrebbe essere la ragione . Poi ci siamo seduti, abbiamo fatto dei test unitari e abbiamo 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 sono stati in genere in grado di individuare il problema (o almeno indicarci la giusta direzione). Abbiamo corretto il bug, i test erano tornati, tutti erano felici.

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

Per quanto riguarda i consigli, puoi provare con il kata TDD; compito semplice da implementare utilizzando un primo approccio di prova invece di nessun test . A seconda della complessità del compito, l'approccio non di test dovrebbe essere di solito più lento, specialmente con le modifiche richieste incrementali:

• Calcolatore di stringhe di Roy
• Bank OCR

Modifica : il commento di OP mi ha fatto capire che a sua disposizione ci sono ancora argomenti più validi: regression alias return bugs . Questo tipo di situazioni sono esempi perfetti che dimostrano come possono essere i test unitari benefici. Alle persone piacciono i numeri - come ho detto, dicendo a "che il test delle unità è buono" potrebbe non essere convincente, ma organizzare i dati come di seguito potrebbe essere sicuramente:

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

Una cosa che ti avvisa (questa nota può essere ovvia ma vale la pena di essere notata): bias dei risultati - assicurati di non selezionare un esempio in cui l'unico modo per individuare il bug con il test era scrivere un test per quel bug. Di solito, nessuno sa che il bug si verificherà in anticipo, ma è allettante dire "man che questo bug sarebbe banale se avessimo il 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 spendere x-hours per sviluppare la funzione Y, perché insistere nel farlo in 2x ?

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

Spesso i programmi di sviluppo sono spesso la ragione, ma tu dici di non averlo.

La prossima ragione è che con una grande base di codice non testata esistente, i test di scrittura probabilmente sembrano schiaccianti: un lavoro senza fine (come il bucato e altrettanto eccitante). Quindi la natura umana è pensare che sia troppo da affrontare, quindi lo salterò.

Un altro motivo potrebbe essere il fatto che, mentre pensano che i test siano una buona idea, non sono sicuri di come iniziare a scriverli, specialmente se non hanno mai lavorato in nessun posto che li abbia scritti.

Un'altra possibilità è che non vedono alcun valore per più lavoro, anche se stanno dando il loro eloquio all'idea.

Quindi come gestisci i diversi motivi?

Il motivo uno è semplice, mostra loro un esempio di come si risparmia il tempo di sviluppo.

Motivo due: mostra quanti test hai scritto in un anno e quale percentuale del codice base copre. Fai i calcoli per mostrare quanti più test potrebbero avere in questo momento il prossimo anno se lo fanno. Una volta che si vedono davvero dei piccoli progressi su base giornaliera, 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 di ripetizione compaiono nel codice con i test unitari.

Il motivo 3 è la formazione, non solo la visualizzazione. Fagli fare dei test di scrittura in un corso di formazione.

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

Un altro modo per affrontare la ragione 4 è far sì che la gestione faccia parte del processo e il codice non passi la revisione del codice a meno che i test non superino anche la revisione del codice. Meglio approcciarli con una polizza giusta dopo uno di quei punti dolenti o preferibilmente subito dopo aver avuto parecchi nel giro di pochi giorni.

A tutti noi piace pensare che come sviluppatori ci auto-gestiamo (LOL), ma gli ambiziosi si preoccuperanno di ciò che la gestione sottolinea loro che dovrebbero preoccuparsi e i professionisti che veramente si autogestiscono stanno già scrivendo i test. Se non si preoccupano di essere professionali e di fare buone pratiche perché migliorano il prodotto o si preoccupano 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 convincere il management a preoccuparsi delle migliori pratiche, allora dovrai affrontare una dura battaglia e, ancora una volta, 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 vantaggi di TDD. Prova a mostrare i vantaggi dei test unitari.

Come normali esseri umani, gli sviluppatori sono motivati dai benefici. Non vogliono fare cose che creano solo più lavoro. Test delle unità significa meno lavoro . Significa uscire con gli amici di più. Significa avere più divertimento perché non devi passare la notte a programmare fino alle 23.00. Significa andare in vacanza di più con la massima tranquillità.

Uno dei maggiori vantaggi di TDD è che puoi refactare il tuo programma per un design migliore o semplicemente cambiare il nome di qualcosa ... e finché quel progetto non rompe i test , puoi avere il 100% di confidenza che il tuo cambiamento non ha infranto nulla.

Un altro ottimo caso per TDD è la creazione di test unitari per il codice legacy . Questo rappresenterebbe uno dei migliori modi per iniziare a rifattorizzare il male. A lungo termine, questo servirà a migliorare la tua conoscenza del codice base, a comprenderne i punti di forza e le imperfezioni, a individuare nel codice la logica aziendale hard-coded e offrirti un buon inizio per migliorare la qualità andando avanti!

Buoni riferimenti per ulteriori letture:

• Perché dovresti scrivere i test delle unità
• Visibilità della motivazione e test unitario
• The arte di test unitari, secondo Roy Osherove

link

Penso di aver inserito il link di un articolo di Jeff Atwood qualche tempo fa [edit: sì, eccolo qui . Vecchio ma pertinente. A causa di questi benefici e di altri che saranno senz'altro delineati in altre risposte, i tuoi programmatori dovrebbero essere in grado di motivarsi ! Permetterà loro di lavorare in modo più efficiente e quindi renderà il loro lavoro un po 'più facile. Chi non lo vuole?

Riguardo alla tua seconda domanda: il tuo senso di appartenenza e l'orgoglio per gli standard di qualità del codice dovrebbero aiutarti a seguirli . Pensa a ciò che vuoi ottenere avendo questi standard e chi ne trae beneficio. Anche i miei standard di codice personale possono essere frustranti, ma mi sento sempre come se facessi un favore al mondo / azienda / squadra implementandoli. Quindi non penso che tu stia cercando di fare troppo - i risultati variano da luogo a luogo, ma almeno stai facendo lo sforzo.

Questo sembra un grande caso di come esempio .

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

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

È molto difficile combatterlo con conferenze, dichiarazioni di gestione o anche con la logica. Devi vincere sfruttando un aspetto alternativo della natura umana.

• Le persone imitano il comportamento dei migliori dipendenti

Se i migliori impiegati usano TDD e funziona, il processo si espanderà. Se non lo fanno, non lo faranno. Se hai bisogno di convincere qualcuno, sono i primi 1 o 2 impiegati.

Chiedi loro.

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

Non può (spesso i tempi non lo è) una questione di semplice motivazione. Potrebbero dimenticarsene. Potrebbero sentirsi sotto pressione. Potrebbero non sapere come scrivere buoni test. Potrebbero pensare che tu sia 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 da soli. Non so come funzioni la tua azienda, ma quando si verifica un problema durante l'implementazione della produzione, lavoriamo fino a quando non viene risolto. Non importa se succede alle 2 di domenica mattina. Questo è molto raro per noi, ma quando lo fa, fa schifo.

Vorrei iniziare chiedendo loro quante volte si sono dovuti alzare nel cuore della notte per risolvere alcuni dei problemi principali che avrebbero potuto facilmente trovare test automatici. Questo non vuol dire che i test automatici risolveranno tutto, ma dovrebbe contribuire a ridurlo.

Il secondo grande venditore è il ciclo di QA. Prima dell'inizio del TDD nella mia azienda, avremmo spinto le nuove versioni al QA per testare ogni settimana. Avrebbero creato una serie di bug fuori da quella release, abbiamo sistemato quei bug e spinto un altro rilascio. Ripeti fino al termine. Il primo progetto che abbiamo fatto a 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 la possibilità di compilare queste statistiche per la tua squadra?

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

Infine, mostra loro come saranno in grado di effettuare il refactoring del codice con sicurezza.

Tieni tutto questo in mente quando non hai voglia di scrivere test. :)

Mi piacerebbe espandere la risposta di HLGEM , in particolare questa sezione:

Next reason is that with a large existing untested code base, writing tests probably seems overwhelming- a never ending job (like laundry and about as exciting). So human nature is to think that's too much to face, so I'll skip it.

Ho trovato 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 posso testare questa funzione? impone un design migliore di ogni singola funzione. (Meno affidamento su dati globali o semi-globali, IO separato dal calcolo, le funzioni fanno solo una cosa: gestione coerente degli errori e così via.)

Provare a mettere i test su vecchio codice che non è stato scritto pensando ai test potrebbe essere frustrante.

Ho usato alcune tecniche:

a) crea una build automatizzata. Quando qualcuno rompe qualcosa che hai testato, mostra loro come il test lo ha rilevato e quanto sarebbe stato cattivo l'errore.

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

c) Fai entrare una persona alla volta. Quello che ti ascolta. Affronta 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, lui ti aiuterà. È un effetto domino.

Cuocia il test delle unità nel processo. Se un bug mostra nella produzione che è troppo ovvio per prendere in unit test allora questo ragazzo 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 i test unitari, le persone chiederanno i requisiti e alla fine legheranno i requisiti allo sviluppo e, auspicabilmente, svilupperanno il software richiesto e funzionante:)