Il test unitario vale lo sforzo, in un codice grande e vecchio (5 anni)?

Question

Mi sono appena unito a un team che ha lavorato in modalità main-always per gli ultimi 5 anni (java, progetto basato su maven). Di conseguenza, i piani per sfruttare i test unitari sono sempre stati in cantiere, mai concretizzati (finora). Un team di sviluppatori ha fatto in modo che la qualità del codice sia generalmente buona e non ci siano problemi di codice strutturale, ma non c'è cultura di scrittura di test jnuit. Ma io, avendo visto i benefici dei test unitari, sono un guerriero solitario che spinge qui per l'adozione dell'auto-testing.

Il layout squadra è tale che un team di testing indipendente fa test manuale di funzionalità prima di stendere il codice, e un team di gestione del cambiamento è una checkgate per l'approvazione del cambiamento e costruisce (senza integrazione continua sia, finora).

Di seguito sono riportati gli ostacoli: poiché la base di codice è enorme e alcuni sviluppatori originali hanno lasciato il team, eventuali test di unità aggiuntivi potrebbero essere insufficienti, troppo tardi. Aggiungete che posso essere l'unico a spingere per il test delle unità. Sebbene il mio manager abbia supportato l'idea, non vuole che il team delle modifiche sia impantanato dal tempo aggiuntivo necessario per l'esecuzione dei test.

Sono dell'opinione che sia possibile utilizzare uno strumento CI autonomo per iniziare e il team di modifiche deve modificare i propri script per saltare i test, come e quando vengono aggiunti.

Cosa faresti nei miei panni?

P.S .: Sono a conoscenza di una domanda simile su stackoverflow, ma in questo caso, l'obiettivo è convincere i diversi stakeholder e il miglior percorso verso il takel; non un confronto tecnologico.

Answer 1

Sembra che tu abbia una buona idea della situazione.

due cose:

1. non ci aspettiamo di essere in grado di completamente unità di prova di un vecchio progetto di 5 anni. Supponendo che 5 sviluppatori lavorino per 5 anni, ti trovi a circa 50.000 ore di programmazione. Supponendo che i test richiedano il tempo necessario per scrivere come codice, si farebbe abbastanza bene per ottenere una copertura del 2-3% in un anno.

2. Quindi: testare il nuovo codice e scrivere test per le modifiche del codice precedente. Ottieni tempo/prenditi il ​​tempo necessario per impostare CI di qualche tipo. A poco a poco, accumulerai una bella batteria di test.

Dal momento che apparentemente non stai affogando nei bug, inizia lentamente, ottieni slancio.

Answer 2

Vale la pena scrivere test per verificare funzionalità specifiche su cui si sta lavorando e si desidera rimanere stabili.

Con una grande applicazione esistente che non ha copertura di test al momento, non si vorrebbe sedersi e scrivere test tutto in una volta, al fine di ottenere una copertura del 100% di test unitario e non lo farete mai. Dovresti solo individuare funzionalità specifiche per i test. Non penso che ci sia qualcosa di troppo piccolo o troppo tardi; i test unitari solo per un po 'di funzionalità molto importanti sono migliori di niente, e alcuni test unitari ora sono migliori di nessun test unitario di sempre.

Answer 3

Il test delle unità è vantaggioso anche in un vecchio progetto, ad esempio, stabilendo test di unità, si può essere sicuri che il problema non è nel codice esistente ma nel nuovo codice (anche se si ha un processo di controllo qualità, i bug continuano a funzionare superare l'occasione). Inoltre, impediscono che le modifiche al vecchio codice introducano sottili differenze di comportamento. Inoltre, i test unitari documentano il comportamento previsto dell'enorme base di codici.

Ora, l'adozione di grandi cambiamenti non è mai facile. La prima e più semplice cosa è mandare un test unitario su tutto il nuovo codice, in modo che lo sforzo e il carico di lavoro dell'unità che collaudano la vecchia base di codice non continui ad accumularsi. Quindi, la seconda parte è prendere l'iniziativa e creare alcuni test unitari per il vecchio codice. Se lo fai, dovresti essere in grado di convincere gli altri membri del tuo team ad aiutare nello sforzo di creare test unitari per il codice esistente. Se necessario, vieni con incentivi divertenti, come promettere una pizza party per il team che crea il maggior numero di test unitari per il codice esistente.

Inoltre, ricorda ai tuoi compagni di squadra che questo non è qualcosa in cui devono abbandonare tutto ciò che stanno facendo ... se creano solo un test unitario per un componente esistente ogni giorno sopra il loro altro lavoro, poi alla fine otterrai un test unitario per tutti i componenti esistenti nella base di codice.

Answer 4

IMHO, unit test o qualsiasi altro test (eccetto test funzionali) devono essere eseguiti frequentemente contro parti dell'applicazione critiche e volatili allo stesso tempo. In altre parole, i test di unità non dovrebbero essere scritti per motivi di scrittura di test, ma piuttosto per garantire che i tecnici di sviluppo/manutenzione non inciampino su determinate condizioni nel codice.

Detto questo, si potrebbe anche voler dare un'occhiata ai test di integrazione eseguiti in un server CI, soprattutto perché sono più vicini ai test funzionali e anche perché il codice è maturo. Dalle mie osservazioni, identificare i test unitari per scrivere in un'applicazione matura è molto difficile e ha un minore ROI nel breve periodo rispetto ai test di integrazione.

I test di integrazione nel tuo caso garantiranno che i vari livelli dell'applicazione continuino a essere mantenuti insieme alle intenzioni degli sviluppatori originali. I test unitari d'altra parte, essendo un po 'più localizzati in natura, assicureranno che qualsiasi nuova correzione patch/bug in una particolare area causi effetti collaterali in quella posizione.

Answer 5

Sarà uno sforzo enorme e i ritorni sarebbero piccoli. Piuttosto automatizza ed espandi i tuoi test correnti per garantire la stabilità del sistema (presumo che ci siano alcuni test a livello di sistema). Penso che dovresti concentrarti su parti del sistema che vedono ancora molti cambiamenti o che prevedi di cambiare nel prossimo futuro.

Il collaudo delle unità è buono ma può essere difficile eseguire il retrofit in un sistema esistente. Se ti concentri solo sui test unitari per il prossimo anno o più, perdi slancio.

Answer 6

Non scriverei test solo per scrivere test. Quale sarebbe il profitto commerciale? La tua azienda probabilmente ha già subito gli effetti di non avere test unitari e ora i problemi sono stati risolti. Se aggiungessi dei test, li aggiungerei solo alle sezioni di codice che causerebbero i risultati più spiacevoli. Ad esempio, prenderei in considerazione l'aggiunta di test a qualsiasi codice relativo al ruolo o alla sicurezza.