Collega non disposto a utilizzare i test unitari "poiché è più da programmare"

Un collega non è disposto a utilizzare i test unitari e, invece, optando per un test rapido, lo passa agli utenti e, se tutto va bene, viene pubblicato dal vivo. Inutile dire che alcuni bug riescono a superare.

Ho detto che dovremmo pensare di usare i test unitari, ma una volta che si è reso conto che avrebbe dovuto scrivere più codice, era tutta contraria. Questo mi lascia nella posizione di modificare qualcosa e non essere sicuro che l'output sia lo stesso, specialmente perché il suo codice è spaghetti e provo a riformattarlo quando ne ho la possibilità.

Qual è il modo migliore per me?

Non è a conoscenza dei vantaggi del test unitario ed è quello 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 vantaggi e ascoltare tutti i suoi argomenti contrari. Aspetta che finisca di parlare prima di iniziare a parlare da solo.

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

Ascoltarla e provare 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 infine cambiare idea.

Scrivi un test unitario (non dirglielo)

Aspetta che la cosa si rompa, Lasciala fare test manuali per due giorni, quindi estrai i test delle unità e trova il bug in tre secondi.

Mettiti al riparo ...

L'automazione di attività manuali altrimenti dovrebbe fare appello a qualsiasi programmatore.

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

(Uno dei) punti di test automatizzati è la ripetibilità . Se fate un test rapido a mano, si può avere fatto più veloce di scrivere la stessa di un test di unità (per un principiante unit testing almeno - chiunque con esperienza nel test di unità può sfornare test piuttosto veloce).

Ma cosa succede quando domani o la prossima settimana viene apportata una piccola (o grande ...) modifica al codice? Il tuo collega ripeterà felicemente gli stessi test manuali più volte dopo ogni modifica, per assicurarsi che nulla sia rotto? O preferirebbe "codificare e pregare"?

Più il codice viene modificato, più i test unitari ripagano il tuo investimento iniziale . Non ci vuole molto per arrivare sul lato positivo, anche se i test non rilevano alcun bug. Ma lo fanno anche regolarmente: a questo punto diventano inestimabili. E una volta che qualcuno prova quella sensazione di sicurezza, e la fiducia nel proprio codice che dà un test unitario riuscito, di solito non si può tornare indietro.

Se è un po 'convinta ma ha paura di avventurarsi nella nuova area, offrile una sessione di programmazione in coppia per scrivere insieme i suoi primi test unitari . Scegli una classe che non è troppo difficile da testare ma abbastanza complessa da valerne la pena.

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

• tassi di difetto nel codice scritto da te contro il suo
• scrivere una serie di test unitari contro il suo codice e documentare i bug trovati.

Raccogli alcuni di questi dati, poi mostrale educatamente i risultati. Se questi non sono ancora sufficienti per convincerla, potrebbe essere necessario discutere il problema e condividere le prove raccolte con il management. Dovrebbe essere solo l'ultima risorsa, ma a volte non c'è altro modo.

Scrivi una copertura di test di base per le parti peggiori del suo codice, elaboralo in base a quei test, quindi fai un caso con la gestione che i test unitari su build continue miglioreranno la produttività. I cambiamenti diventano più facili se richiesti da un datore di lavoro piuttosto che evangelizzati da un singolo sviluppatore.

Non so come esprimerlo correttamente, ma: se stai riformattando il suo codice "quando ne avrai la possibilità" ... beh, probabilmente pensa che tu sia un po 'idiota per coinvolgerti nei "suoi affari" , quindi è meno probabile che ti ascolti con una mente aperta. Nella mia esperienza, le persone si affezionano a ciò che hanno fatto, anche quando non è terribilmente buono.

Interpretare l'avvocato dei diavoli: ha ragione. Di solito lo metto come:

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

Fondamento logico:

• studio sulla correlazione della frequenza dei guasti e delle metriche OO , risultato del titolo: "Dopo aver controllato la dimensione [della classe], nessuna delle metriche che abbiamo studiato è stata associata più alla propensione ai guasti" . (Lo studio discute la dimensione della classe. Questo effetto si estende alla dimensione della base di codice? Probabilmente. Secondo me )
• Empiricamente, i grandi progetti tendono ad andare avanti lentamente. "5K linee durante la notte in un nuovo progetto" vs. "10 linee / giorno su una grande". Indica una "resistenza" che cambia con l'aumentare della dimensione della base di codice?
• Proclamiamo sempre "non esiste la lingua migliore, dipende dal problema". Un requisito chiave è la modellazione semplice di entità e operazioni problematiche nella lingua prescelta. Ciò non suggerisce che scegliere una lingua in cui esprimere il tuo problema sia più elaborato sia peggio , e ciò non sia nuovamente correlato con la dimensione finale della base di codice?

Ora, ci sono alcuni argomenti a cui rispondere facilmente. Lasciami indirizzare quelli a cui riesco a pensare:

• dimensioni vs. semplicità: ovviamente è possibile abbreviare e ridurre il codice. Tuttavia, questo è solo un problema quando si confrontano le basi di codice con diversi rapporti di brevità contro semplicità, per la discussione che si può presumere che in qualche modo possiamo controllare questo fattore.

• I test unitari ti spingono a ridurre le dipendenze e concordo empiricamente sul fatto che ridurre le dipendenze può mitigare i problemi di dimensione del codice (nel senso che di due basi di codice di dimensioni simili, quella con più interdipendenze è peggio). Tuttavia , pur riducendo le dipendenze tra le unità di codice di produzione, introduce l'accoppiamento tra il test e l'unità stessa.

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

Penso che tu sia in una posizione difficile. Sono stato in un team in cui le persone non avrebbero scritto test unitari o, peggio, orribili test unitari non mantenibili. Ma tutti erano consapevoli del fatto che i test unitari sono buoni.

Quindi ottenere una buona qualità della suite di test unitari del team è stata una strada lunga e difficile. Sempre alla ricerca di dove le cose potrebbero essere migliorate, 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 unitari costringa un design liberamente accoppiato. Quindi convincerla a scrivere il test potrebbe sperare a lungo termine di migliorare anche il codice "reale".

Ma penso che alla fine, sia una decisione del team (non so quanti siete nel team?). Se il team riesce a raggiungere un consenso sul fatto che ci dovrebbe essere una suite di test unitari ben coperta, allora tutti devono conformarsi, condividere esperienze e lasciare che il proprio team cresca forte insieme.

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

Lei è il capo?

Se è così ... sei un po 'bloccato a meno che tu non riesca a convincerla dei benefici che sono fondamentalmente sulla falsariga di "un'oncia di prevenzione vale una libbra di cura". I bug superano. TDD aiuta a mitigarlo creando un output coerente.

Lei non è il capo?

Quali sono gli standard di codifica in cui lavori? Perché le è permesso vomitare il codice spaghetti? Presentare un caso aziendale al capo dicendo "Dedicheremo molto meno tempo ai bug se dedicheremo un po 'più tempo al TDD". Convincere qualcuno che può imporre il cambiamento con un caso aziendale.

Documentare i casi in cui TDD avrebbe potuto risparmiare tempo e $$ SOLDI $$.

Questo bug si è presentato. Sarebbe stato catturato prima di andare in diretta. Trascorrere 2 ore di prevenzione ci avrebbe risparmiato 10 ore di cura. È successo qui, qui e qui. Quelle 10 ore di lavoro che avrebbero risparmiato all'azienda 30 ore di lavoro. Sono così tanti soldi.

Questo mi lascia nella posizione di modificare qualcosa

Perché?

Hanno creato il problema. Dovrebbero risolverlo.

Quale manager sta permettendo che ciò accada? Perché il codice errato di qualcun altro ora è il tuo problema?

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

Nulla cambierà se non avvertono il dolore di scarsa qualità.

È abbastanza corretta, i test unitari sono "più codice".

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

Sfidala su:

1. Cosa succede se qualcuno che non ha familiarità con il codice cambia qualcosa.
2. Cosa succede se qualcuno che non ha esperienza cambia qualcosa.
3. Il costo di manutenzione di un sistema non è misurato in quanto tempo ci vuole per creare. È una proposta a più lungo termine. Pensa al costo totale di proprietà.
4. La sua stima (se era richiesta prima dell'inizio della codifica) dovrebbe includere l'obbligo di scrivere test unitari. Gli uomini d'affari non creano requisiti che richiedono test unitari direttamente, ma hanno un implicito requisito di qualità e richiedono che i cambiamenti futuri non siano pieni di bug o che lo stesso programmatore ne cambi l'origine.

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

Può essere una vendita difficile. Non sono ancora stato in grado di vendere i miei colleghi ai test unitari. So che tendo a fare molti più errori nel mio codice di test dell'unità che nel mio codice di produzione. Quindi, è un po 'frustrante dover passare così tanto tempo a sistemare il codice unit test ... Tuttavia, è una buona assicurazione quando il codice viene modificato. Ottimo modo per testare automaticamente le condizioni dei bordi.

Dimostrale quanto aiutano i test unitari creando tu stesso i test unitari.

Come disse una volta San Francesco, "Predica sempre. Se 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ù rapidamente con i test unitari, potrebbe cambiare idea. Ma potrebbe non esserlo.

Indipendentemente dal risultato, non ti vede spingere su di lei qualcosa che non sei disposto a fare. Questo è ciò che devi cambiare, la percezione che non stai guidando con l'esempio.