Collega riluttante a utilizzare i test unitari "dato che è più codificato"

Non è consapevole dei vantaggi del test delle unità e questo è ciò che devi cambiare:

• La sua consapevolezza.

Dovrai dimostrarle che migliorerà il suo lavoro non solo il tuo. Sarà difficile, probabilmente cercherà di concentrarsi su ogni aspetto negativo che potrebbe trovare se ha paura del cambiamento.

Puoi provare a discutere con lei di tutti i benefici e ascoltare tutti i suoi argomenti contrari. Aspetta che finisca di parlare prima di iniziare a parlare da solo.

Per prepararti, dovresti guardare su P.SE o Google per la gestione di tutte le cose o gli sviluppatori sono preoccupati per il test delle unità e compilare le risposte che utilizzerai durante le discussioni con il tuo collega.

Ascoltarla e dare prova che migliorerà il suo lavoro ti aiuterà molto. Dimostri di essere preoccupato per la sua opinione e le fornisci tutti i dati di cui ha bisogno per analizzare la situazione e alla fine cambiare idea.

Scrivi un test unitario (non dirglielo)

Aspetta che la cosa si rompa, fagli fare test manuali per due giorni, poi estrai i tuoi test unitari e trova bug in tre secondi.

Vai al riparo ...

Automatizzare le attività altrimenti manuali dovrebbe fare appello a qualsiasi programmatore.

Quindi non sta "scrivendo più codice" ma sta facendo meno manualmente.

(Uno dei) il punto (i) dei test automatici è ripetibilità . Se esegui un test rapido a mano, potresti eseguirlo più velocemente rispetto a scrivere lo stesso di un test unitario (almeno per un principiante che collauda unità) - chiunque abbia esperienza in un test di unità può sfornare test abbastanza velocemente ).

Ma quando domani o la prossima settimana verrà apportata una modifica piccola (o grande ...) al codice? Il vostro collega ripeterà allegramente gli stessi test manuali più e più volte dopo ogni modifica, per garantire che nulla sia rotto? O preferirebbe "programmare e pregare"?

Più il codice viene modificato, più i test unitari ripagano il tuo investimento iniziale . Non ci vuole molto per ottenere il lato positivo, anche senza i test in realtà cattura eventuali bug. Ma lo fanno anche regolarmente - a questo punto, diventano inestimabili. E una volta che qualcuno sperimenta quella sensazione di sicurezza e la sicurezza nel proprio codice che dà esito positivo a un test, di solito non si torna indietro.

Se è convinta ma ha paura di avventurarsi nella nuova area, offrigli una sessione di programmazione di coppia per scrivere insieme i suoi primi test unitari . Scegli una classe che non sia troppo difficile da testare ma abbastanza complessa da meritare la prova.

Tuttavia, se non è convinta, potresti dover continuare a raccogliere fatti concreti . Tali fatti potrebbero essere

• tasso di errore nel codice scritto da te o suo
• scrivendo una serie di test unitari contro il suo codice e documentando i bug trovati.

Raccogli alcuni dati, quindi mostrali educatamente i risultati. Se questi non sono ancora sufficienti per convincerla, potrebbe essere necessario discutere il problema e condividere le prove raccolte con la direzione. Questa dovrebbe essere solo la tua ultima risorsa, ma a volte non c'è altro modo.

Scrivi una copertura di test di base per i bit peggiori del suo codice, rafactor basato su quei test, quindi fai un caso con il management che testare le unità su build continui migliorerà la produttività. I cambiamenti arrivano più facilmente quando sono richiesti da un datore di lavoro piuttosto che evangelizzati da un singolo sviluppatore.

Non so come esprimerlo correttamente, ma: se stai refactoring il suo codice "quando ne hai la possibilità" ... beh, probabilmente pensa che sei un po 'un idiota per il coinvolgimento in te stesso " la sua attività ", quindi è meno probabile che ti ascolti con una mente aperta. Nella mia esperienza, le persone si attaccano a ciò che hanno fatto, anche quando non è molto bello.

Per giocare ai diavoli avvocato: lei ha un punto. Di solito lo metto come:

I test automatici risolvono i problemi di molto codice con ancora più codice.

Fondamento:

• studio sulla correlazione tra tasso di errore e metrica OO , titolo principale: "Dopo aver controllato le dimensioni [della classe], nessuna delle metriche che abbiamo studiato era associata alla" mancanza di difetti ". (Lo studio discute le dimensioni della classe: questo effetto si estende alla dimensione della base di codice? Probabilmente. Nella mia opinione )
• Empiricamente, i progetti di grandi dimensioni tendono ad andare avanti lentamente. "5K linee durante la notte in un nuovo progetto" contro "10 linee / giorno su un grande". Indica una "resistenza" per cambiare aumentando con la dimensione della base del codice?
• Diciamo sempre "non esiste una lingua migliore, dipende dal problema". Un requisito chiave è la modellazione delle entità problematiche e delle operazioni facilmente nella lingua prescelta. Non suggerisce che scegliere un linguaggio in cui esprimere il tuo problema sia più elaborato è peggio , e che non è ancora correlato con la dimensione finale del codice base?

Ora, ci sono alcuni argomenti su cui sparare facilmente. Lasciatemi indirizzare quelli a cui riesco a pensare:

• dimensioni rispetto alla semplicità: ovviamente è possibile rendere il codice sempre più breve. Tuttavia, questo è solo un problema quando i confronti si basano su basi di codice con diversi rapporti di brevità-vs-semplicità, per la discussione si può presumere che potremmo in qualche modo controllare per questo fattore.

• I test unitari ti spingono a ridurre le dipendenze e sono d'accordo sul fatto che ridurre le dipendenze può mitigare i problemi relativi alle dimensioni del codice (nel senso di due basi di codice di dimensioni simili, quella con più interdipendenze è peggiore). Tuttavia , riducendo al contempo le dipendenze tra le unità del codice di produzione, introduce l'accoppiamento tra il test e l'unità stessa.

TL; DR: Non discuto che i test unitari siano cattivi; Chiedo: c'è un punto di pareggio in cui i test danneggiano che è correlato alla quantità di codice?

Penso che tu sia in una posizione difficile. Sono stato in una squadra dove le persone non avrebbero scritto test unitari, o peggio, test unitari orribili non mantenibili. Ma tutti erano consapevoli del fatto che il test unitario è buono.

Quindi ottenere una buona qualità della suite di test del team era una strada lunga e difficile. Sempre alla ricerca di dove poter migliorare le cose, comunicare idee, condividere esperienze.

D'altra parte hai uno sviluppatore che non ha nemmeno realizzato il vantaggio. E poi codifica anche il codice spaghetti. Immagino che uno dei motivi più importanti in questo caso particolare sia il fatto che la scrittura di buoni test di unità costringe a un design unilaterale. Quindi convincerla a scrivere il test potrebbe, a lungo andare, migliorare anche il codice "reale".

Ma penso che alla fine, è una decisione di squadra (non so quanti siete nella squadra?). Se il team riesce a raggiungere un consenso sul fatto che ci dovrebbe essere una suite di test unitaria ben coprente, allora tutti devono conformarsi, condividere esperienze e far crescere strong la squadra.

Se tuttavia la squadra non riesce a raggiungere un consenso sul fatto che dovresti scrivere dei test unitari, ti suggerisco di trovare un team di sviluppo diverso con cui lavorare;)

Lei è il capo?

Se è così ... sei piuttosto bloccato a meno che non riesci a convincerla dei benefici che sono fondamentalmente sulla falsariga di "un'oncia di prevenzione vale un chilo di cura". Gli insetti arrivano. TDD aiuta a mitigarlo creando un output coerente.

Non è lei il capo?

Quali sono gli standard di codifica in cui lavori? Perché è autorizzata a diffondere il codice degli spaghetti? Presentare un caso aziendale al capo dicendo "Passeremo molto meno tempo ai bug se trascorriamo un po 'più di tempo su TDD". Convinci qualcuno che può imporre il cambiamento con un business case.

Casi di documenti in cui TDD avrebbe potuto risparmiare tempo e amp; $$ SOLDI $$.

Questo bug si è presentato. Sarebbe stato catturato prima di andare a vivere. Trascorrere 2 ore di prevenzione ci avrebbe risparmiato 10 ore di cura. È successo qui, qui e qui. Quelle 10 ore di lavoro che avrebbero salvato la compagnia per 30 ore lavorative. Sono tanti soldi.

This leaves me in the position of modifying something

Perché?

Hanno creato il problema. Dovrebbero risolverlo.

Quale manager sta permettendo che questo accada? Perché il codice bug di qualcun altro ora è il tuo problema?

Hai un collega e un manager che stanno facendo in modo che ciò accada. E ripulendo il loro casino, sei un partecipante disponibile e attivo.

Nulla cambierà se non sentiranno il dolore di una scarsa qualità.

Ha ragione, i test unitari sono "altro codice".

Tuttavia è semplicemente più codice che deve essere scritto per accertare che il programma funzioni come dovrebbe (più e più volte). Non è tempo perso. È tanto parte del sistema quanto i suoi componenti principali.

Sfidala su:

1. Cosa succede se qualcuno che non ha familiarità con il codice cambia qualcosa.
2. Che cosa succede se qualcuno che è inesperto cambia qualcosa.
3. Il costo del mantenimento di un sistema non è misurato in come tempo necessario per creare. È una proposizione a lungo termine. Pensa a il costo totale di proprietà.
4. Il suo preventivo (se necessario prima dell'inizio della codifica) dovrebbe includere l'obbligo di scrivere test unitari. Gli uomini d'affari non creano requisiti che richiedono direttamente test unitari, ma hanno un implicito requisito di qualità e richiedono che le modifiche future non siano piene di bug o che lo stesso programmatore cambi la sua fonte.

Parlando come uno che attualmente fa codice di produzione, seguito da test unitari piuttosto che TDD, che non sembra essere una buona idea al mio posto attuale (ho fatto TDD su alcuni progetti, ma lo vedo come un altro strumento nella vecchia borsa, non un proiettile d'argento) ...

Può essere una vendita difficile. Non sono ancora riuscito a vendere i miei collaboratori ai test unitari. So che tendo a generare molti più errori nel mio codice di test delle unità rispetto al mio codice di produzione. Quindi, è un po 'frustrante dover spendere così tanto tempo a sistemare il codice di test unitario ... Comunque, è una buona assicurazione quando il codice viene modificato. Ottimo modo per testare automaticamente le condizioni del bordo.

Mostra quanti test unitari ti aiutano creando tu stesso i test unitari.

Come disse una volta San Francesco: "Predica sempre, quando è necessario, usa le parole"

Se vede che il tuo codice sta usando i test unitari e che sei in grado di risolvere i bug più velocemente con i test unitari, allora potrebbe cambiare idea. Ma non può.

Non importa il risultato, lei non ti vede come qualcosa che le spinge e che non sei disposto a fare. Questo è ciò che devi cambiare, la percezione che non stai guidando con l'esempio.