Qual è il modo più convincente per richiedere test unitari formalizzati?

https://stackoverflow.com/questions/120460

02-07-2019
|

Domanda

Ciò presuppone certamente che i test unitari siano una buona cosa. I nostri progetti hanno un certo livello di test unitari, ma nella migliore delle ipotesi non è coerente.

Quali sono i modi più convincenti che hai usato o che hai usato con te per convincere tutti che il test unitario formalizzato è una buona cosa e che renderlo necessario è davvero nel migliore interesse dei progetti "grandi" su cui lavoriamo . Non sono uno sviluppatore, ma sono in garanzia della qualità e vorrei migliorare la qualità del lavoro svolto per assicurarmi che sia pronto per essere testato.

Con test unitari formalizzati, sto semplicemente parlando di

Identificazione dei test unitari da scrivere
Identificazione dei dati del test (o descrizione)
Scrivere questi test
Monitoraggio di questi test (e riutilizzo secondo necessità)
Rendere disponibili i risultati

Soluzione 13

Quindi, due anni dopo aver fatto questa domanda, ho scoperto che una risposta inaspettata era che passare a un nuovo SDLC era ciò che era necessario. Cinque anni fa, abbiamo creato il nostro primo SDLC formale. Ha migliorato la nostra situazione, ma ha lasciato fuori alcune cose importanti, come l'automazione. Ora siamo in procinto di stabilire un nuovo SDLC (sotto nuova gestione) in cui uno degli inquilini è l'automazione. Non solo test unitari automatizzati, ma test funzionali automatizzati.

Immagino che la lezione sia che stavo pensando troppo in piccolo. Se hai intenzione di cambiare il modo in cui crei il software, fai "tutto il resto" e fai un cambiamento drastico piuttosto che proporre un cambiamento incrementale se non sei abituato a questo.

Altri suggerimenti

Un modo molto convincente è quello di fare un test unitario formalizzato, indipendentemente da ciò che fa il tuo team / azienda. Questo potrebbe richiedere un ulteriore sforzo da parte tua, soprattutto se non hai esperienza con questo tipo di pratica.

Quando puoi mostrare che il tuo codice è migliore e sei più produttivo dei tuoi colleghi sviluppatori, vorranno sapere perché. Quindi dai loro i tuoi metodi di test delle unità preferiti.

Dopo aver convinto i tuoi colleghi sviluppatori, convincere il management insieme.

Uso Maven con Surefire e Plugin Cobertura per tutte le mie build. I casi di test effettivi vengono creati con JUnit , DbUnit e EasyMock .

Identificazione di test unitari Cerco di seguire Test Driven Development, ma ad essere sincero di solito lo faccio solo per la manciata di casi di test e poi torno e creo test per i casi limite e di eccezione in seguito.

Identificazione dei dati dei test DbUnit è ottimo per caricare i dati di test per i test unitari.

Casi di prova di scrittura Uso JUnit per creare i casi di test. Cerco di scrivere casi di test autodocumentati ma userò Javadocs per commentare qualcosa che non è ovvio.

Tracking & amp; Rendere disponibili i risultati Integra il test unitario nel mio ciclo di compilazione Maven usando il plug-in Surefire e utilizzo il plug-in Corbertura per misurare la copertura raggiunta da questi test. Genero e pubblico sempre un sito Web che include i report Surefire e Cobertura come parte della mia build giornaliera in modo da poter vedere quali test sono falliti / superati.

L'evento che mi ha convinto è stato quando siamo riusciti a regredire un bug tre volte, in tre versioni consecutive. Una volta capito quanto ero più produttivo come programmatore quando non correvo costantemente errori insignificanti dopo che erano andati al cliente, e potevo avere una calda sensazione sfocata che il codice dei colleghi avrebbe fatto quello che sostenevano, sono diventato una conversione.

Ai tempi in cui ho fatto lo sviluppo di Cobol su Mainframe, lo abbiamo fatto religiosamente nelle diverse aziende in cui ho lavorato ed è stato accettato come hai fatto tu perché l'ambiente lo ha imposto. Penso che sia stato uno schema molto tipico per l'epoca e forse alcuni dei motivi potrebbero essere applicabili a te: -

Come la maggior parte degli ambienti mainframe, abbiamo avuto tre ambiti, sviluppo, controllo qualità e produzione. I programmatori si sono sviluppati nello sviluppo e hanno testato l'unità lì, e una volta firmati e soddisfatti, l'unità è stata migrata nell'ambiente QA (con i documenti di test e risultati) dove è stata testata dal sistema da personale dedicato al QA. Lo sviluppo della migrazione del QA è stato un passaggio formale avvenuto durante la notte. Una volta eseguito il QA, il codice è stato migrato su Production - e abbiamo avuto pochissimi bug.

La motivazione per eseguire correttamente i test unitari è stata che se non lo hai fatto e un bug è stato trovato dal personale addetto al controllo qualità, era ovvio che non avevi svolto il lavoro. Di conseguenza la tua reputazione dipendeva da quanto fossi rigoroso. Naturalmente la maggior parte delle persone finirebbe con un bug occasionale, ma i programmatori che hanno prodotto codice solido e testato per tutto il tempo hanno presto ottenuto una reputazione da star e anche quelli che hanno prodotto codice errato sono stati notati. La spinta sarebbe sempre quella di migliorare il tuo gioco, e di conseguenza la cultura prodotta era quella che spingeva verso il codice privo di bug consegnato la prima volta.

Estrazione di punti pertinenti -

Reputazione del programmatore legata alla consegna di codice testato privo di bug
Le spese generali significative associate allo spostamento del codice dell'unità testata al livello successivo, quindi la motivazione a non ripetere questo e farlo correttamente la prima volta.
Test di sistema eseguiti da persone diverse per test unitari - idealmente un team diverso.

Sono sicuro che il tuo ambiente sarà diverso ma i principali potrebbero essere traducibili.

A volte, per esempio, è il modo migliore. Trovo anche che ricordare alle persone che certe cose non accadono quando le cose sono sotto test. La prossima volta che qualcuno ti chiede di scrivere qualcosa, fallo con i test a prescindere. Alla fine i tuoi colleghi saranno gelosi della facilità con cui puoi cambiare il tuo codice e sapere che funziona ancora.

Per quanto riguarda la gestione, è necessario sottolineare quanto tempo viene sprecato a causa dell'esplosione nucleare che si verifica quando è necessario apportare una modifica alla base di codice X che non è in fase di test.

Molti sviluppatori non si rendono conto di quanto rifattorizzano senza assicurarsi di preservare il comportamento nell'intero sistema. Per me questo è il più grande vantaggio per i test unitari e TDD secondo me.

Modifica dei requisiti software
Modifiche al software per soddisfare i requisiti

L'unica certezza è il cambiamento. La modifica del codice che non è in fase di test richiede allo sviluppatore di essere consapevole di ogni possibile effetto collaterale comportamentale. La realtà è che i programmatori che pensano di poter leggere ogni permutazione, lo fanno attraverso un processo di picchettamento di tentativi ed errori fino a quando nulla si rompe ovviamente. A questo punto effettuano il check-in.

Il programmatore pragmatico riconosce di non essere perfetto e ben informato, e che i test sono come una rete di sicurezza che consente loro di camminare sul filo del refactoring in modo rapido e sicuro.

Per quanto riguarda quando scrivere test su codice greenfield, dovrei sostenere il più possibile. Dedica il tempo a definire i comportamenti che desideri uscire dal tuo sistema e scrivi inizialmente dei test per esprimere quei costrutti di livello superiore. I test unitari possono arrivare quando i pensieri si cristallizzano.

Spero che questo aiuti.

Istruzione e / o certificazione.

Offri ai membri del tuo team una formazione formale nel campo dei test, magari con un esame di certificazione (a seconda dei membri del tuo team e del tuo atteggiamento nei confronti della certificazione). In questo modo porterai i test a un livello superiore e i membri del tuo team avranno maggiori probabilità di assumere un atteggiamento professionale nei confronti dei test.

Esiste una grande differenza tra convincente e che richiede .

Se trovi un modo per convincere i tuoi colleghi a scriverli, fantastico. Tuttavia, se si creano alcune regole formalizzate e si richiede loro di scrivere unit test, troveranno un modo per superare questo. Di conseguenza otterrai un sacco di test unitari che non valgono nulla: ci saranno test unitari per ogni singola classe disponibile e testeranno setter e getter.

Pensaci due volte prima di creare e applicare le regole. Gli sviluppatori sono bravi a superarli.

La prima volta che vai in giro devi solo andare avanti e scriverli e mostrare alle persone che ne vale la pena. Ho scoperto su tre progetti che è l'unico modo per convincere le persone. Alcune persone che non codificano (ad es. I project manager junior) non saranno in grado di vedere il valore finché non li fisserà in faccia.

Nel mio team di software, tendiamo a scrivere un piccolo caso aziendale su questi problemi e presentarli alla direzione per avere il tempo disponibile per creare e tenere traccia dei test. Spieghiamo che il tempo impiegato per il test è ben compensato quando arriva il momento critico e tutto è in linea. Abbiamo anche creato un server di build Hudson per centralizzare il monitoraggio dei test unitari. Questo rende molto più facile per gli sviluppatori tenere traccia dei test falliti e scoprire problemi ricorrenti.

Ricorda al tuo team o agli altri sviluppatori che sono professionisti, non dilettanti. Ha funzionato per me!

Inoltre, è uno standard del settore in questi giorni. Senza esperienza di unit test, sono meno desiderabili e meno preziosi in quanto dipendenti per potenziali futuri datori di lavoro.

In qualità di responsabile del team, è mia responsabilità garantire che i miei programmatori stiano eseguendo test di unità su tutti i moduli su cui lavorano. Suppongo che a questo punto non sia nemmeno una questione di come convincerli, è necessario. Non a volte, non su progetti di grandi dimensioni, per tutto il tempo. Il test unitario è la prima linea di difesa contro la messa in produzione di qualcosa che dovrai mantenere. Se qualcosa viene messo in produzione che non è stato completamente testato dall'unità e dal sistema, tornerà a morderti. Immagino che una delle politiche che abbiamo qui per supportare questo sia che se si verifica un salto nella produzione o causa problemi, il programmatore responsabile della codifica e del test di quel modulo sarà quello che dovrà occuparsi dei problemi, fare la pulizia , ecc. Questo da solo è un buon motivatore.
L'altro è che si tratta di orgoglio. Lavoro in un negozio di circa 75 programmatori, anche se è grande per alcuni standard, è davvero abbastanza piccolo perché tutti noi possiamo conoscerci. È anche abbastanza piccolo da sapere a cosa sta lavorando l'un l'altro e quando passa alla produzione, siamo a conoscenza di eventuali interruzioni, guasti, ecc. Se stai attento, esegui i test dell'unità e del sistema, le possibilità di spostare qualcosa alla produzione senza causare guasti aumenta in modo significativo. Potrebbero volerci un paio di volte a spostare qualcosa nella produzione e non riuscire a realizzarlo, ma ci sono grandi ricompense nel non sbagliare. È davvero bello sentire congratulazioni in corridoio quando si sposta un progetto e non si rovina.

Scrivine alcuni e dimostra che i test unitari hanno migliorato la tua produttività e la qualità del tuo codice. Senza una sorta di prova, a volte le persone non credono che ne valga la pena.

Potresti trarre ispirazione da un'iniziativa di Google. Il loro team di test ha iniziato a mettere esempi, suggerimenti e vantaggi all'interno dei gabinetti per aumentare il profilo dei vantaggi dell'automazione dei test.

https://testing.googleblog.com/2007 /01/introducing-testing-on-toilet.html

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow