Il test perde la sua efficacia se tutti i programmatori non li usano

I test di uno devono essere considerati attendibili per essere efficaci. Un uomo con due orologi non sa che ore sono. Cioè: i test cattivi, inaccurati, non mantenuti rovinano le cose buone. Inoltre, una negligenza benevola è una spirale mortale, in ultima analisi, al punto che la suite di test nel suo complesso sarà screditata e abbandonata.

Un test può essere cattivo perché non è attuale o mente. Non importa quale, il danno da fidarsi è lo stesso.

Quando si tratta di test, l'accuratezza mantenuta e la qualità rispetto alla quantità sono fondamentali.

Il test delle unità è una decisione tutto o niente per una squadra. Con questo intendo dire che tutti devono essere sottoposti a test unitari per farlo funzionare. Se non c'è un buy-in a livello di squadra per i test unitari, stai solo creando più codice per mantenerlo potenzialmente interrotto e fuori sincrono, sprecando il tempo e l'impegno di tutti.

Questo non è un problema con il test unitario in particolare. È un problema generale che le tecniche di programmazione non funzioneranno per un team se alcuni membri del team non lo supportano.

La separazione dei livelli si interromperà se un membro del team decide di inserire alcune logiche di business nel livello di presentazione.

Il mio schema di sicurezza per un'applicazione database centric fallirebbe se un membro del team scrivesse stored procedure frontali che non chiamavano la mia procedura che convalida la sessione e controlla le autorizzazioni.

Se un membro del team viola le convenzioni di denominazione, non puoi fare affidamento sui nomi come previsto.

Se il tuo team vuole utilizzare il test dell'unità e un membro del team lo sta rovinando, quel membro non è adatto per il tuo team.

I test unitari vanno di pari passo con l'integrazione continua. Quando qualcuno cambia codice e lo controlla nel tuo controllo sorgente, lo strumento CI (ad es. Jenkins ) dovrebbe ricostruire il tuo progetto con il nuovo codice ed eseguendo OGNI test di unità. Se un test fallisce, la compilazione fallisce e l'elemento della configurazione deve informare tutti gli utenti via email.

Quando le persone si ammalano di ricevere l'e-mail, potrebbero rendersi conto che se eseguono semplicemente i test PRIMA di controllare il codice, allora la vita sarà più facile e tutti saranno felici.

Ognuno deve apprezzare il beneficio che i test unitari portano per poter avere qualsiasi valore. Ho confrontato i test unitari con un nuovo cucciolo: sono fantastici, ma richiedono amore e cura, altrimenti li trovi morti nell'angolo che strisciano con le formiche dopo poche settimane.

Ho visto alcuni scenari della mia carriera fino ad ora:

1. Tutti scrivono buoni test unitari, i test fanno parte di una build CI e il codice viene scritto nei test, non il contrario.
2. Sono l'unica persona che scrive i test di unità e la soluzione a un test non funzionante può essere commentata o semplicemente inserire Assert.IsTrue(true); in
3. Le persone scrivono test sul loro codice. Con questo, voglio dire che qualcuno scrive un mucchio di codice, lo esegue con una serie di input, ottiene un set di output e incolla ciecamente l'output in un test. Questo è il modo in cui si finisce con una correzione di bug legittima che si traduce in una serie di interruzioni di test, che tendono a portare allo scenario n. 2 ("Non abbiamo tempo per correggere questi 30 test, basta commentarli!")

Se vuoi scrivere test unitari, buono . Se nessun altro lo desidera, è tempo di trovare un altro team con cui lavorare.

The person updating the test better have a firm understanding of the reasoning behind the code change and decide if the test or the new code needs to be fixed. This much inconsistency in a team when it comes to testing is probably an indication of other problems as well.

Penso che sia il contrario. Quando il test è buono, il suo fallimento dovrebbe guidare nel decidere se (e perché, e, idealmente, in che modo) modificare il codice o il test.

In questo senso, la responsabilità non inizia con la persona che aggiorna il test ma con persona che crea il test .

Colui che crea il test dovrebbe avere una migliore comprensione del ragionamento alla base del codice . Se questo non è il caso, il test è di scarso valore e bisognerebbe smettere di preoccuparsi di cambiarlo, o addirittura rimuoverlo se effettivamente si trova in una modalità di sviluppo.

Se il test produce nient'altro che lancinanti incomprensibili a ragionevoli cambiamenti di codice, questo è un problema nel test - questo è ciò che deve essere corretto.

There is a certain amount of risk involved that someone else on the team will alter code that is covered by testing. Is this the point where testing becomes counter-productive?

Meno produttivo - forse. Counter produttivo - difficilmente.

L'intervallo di tempo tra le modifiche al codice e l'esecuzione del test può sembrare innaturale per qualcuno utilizzato per maturare forme di test dell'unità e potrebbe effettivamente incorrere in perdite di efficacia, ma in altre forme di test (funzionale, integrazione, controllo qualità) è una cosa abbastanza comune e non è considerato un motivo per abbandonare i test.

Affrontare l'esecuzione del test è in ritardo, probabilmente è necessario uscire dagli schemi degli approcci "classici" di test unitario e osservare come i nostri colleghi tester fanno il loro lavoro.

Ora, immagina che qualcuno qualche tempo fa abbia cambiato codice e qualche tempo dopo esegui il test e fallisce. Pensa a come il tester potrebbe gestirlo ...

1. Errore nel test di studio
2. Se il test ti aiuta a trovare un bug nel codice, ottimo - apri il ticket in tracker dei problemi per risolverlo.
   _{Nota, in seguito puoi utilizzare questi ticket per giustificare i vantaggi dell'esecuzione dei test nei tempi di costruzione, ovvero se i test sono davvero utili.}
3. Se il test non aiuta, modificalo per far corrispondere le modifiche al codice (hai paura di questo? Se sì, che può effettivamente diventare controproducente).
4. Se ritieni che ci sia un problema nel test ... indovina cosa? apri il ticket in issue tracker per farlo correggere.
   _{Nota, in seguito puoi usare questi dati per spiegare perché i bug di regressione scivolano e giustificano la necessità di investire gli sforzi nei test.}

Qui è dove potresti riscontrare una perdita di produttività, perché agisci come tester con lo strumento che è destinato a essere utilizzato dallo sviluppatore. Questo non va bene, ma non proprio la fine del mondo, non credi.

Idealmente l'intera squadra dovrebbe usare test e altre buone pratiche, ma non è sempre realistico - Se non hai il potere di dire al resto del team cosa usare, devi portare tutto il team a d'accordo può significare che i miglioramenti non accadono mai.

Fortunatamente la maggior parte di questi miglioramenti è utile anche se sei l'unico a utilizzarli. Normalmente i test vengono eseguiti su commit per rispondere alla domanda "Il mio codice ha infranto qualcosa?", Ma gli stessi test possono essere eseguiti al checkout per rispondere alla domanda "Qualcun altro ha infranto il mio codice?", Che è ancora più utile in alcuni ambienti .

Questo approccio ti consente di introdurre test a uno sviluppatore alla volta, il che è molto più facile che far concordare tutti. Alla fine tutti useranno i test e potrai iniziare a fare cose come richiedere test per passare sul server di build.

Modifica Le mie opinioni sono completamente cambiate da quando ho introdotto per la prima volta il concetto di copertura del codice. Non mi piace più questa metrica, e al di sotto dei consigli va contro il mio credo ora. Si dovrebbe usare la metrica di copertura del codice per conoscere il codice che potrebbe richiedere ulteriore attenzione. Mai dovrebbe essere impostato il target di X% coverage poiché spesso gli sviluppatori scrivono i test unitari per un motivo errato (ottenere invece la copertura di testare correttamente il codice) e sprecare tempo che potrebbe essere speso per qualcosa di più improtante.

Grazie a qualcuno che ha votato questo post, non l'avrei trovato altrimenti.

[Risposta originale] Potresti utilizzare la copertura del codice come metodo per richiedere agli sviluppatori di lavorare sui test. I test devono essere eseguiti prima del check-in e se il nuovo codice determina una regressione della copertura del codice è semplice da osservare. I rapporti sulla copertura del codice hanno anche buoni rapporti su base per modulo / per classe - in questo modo sarai in grado di vedere chiaramente il cui codice non è coperto e dove è necessario dedicare più tempo per ottenere una copertura migliore .

Stabilisci un obiettivo per il tuo team, ad esempio la copertura del 60% del codice e cerca di mantenerlo tramite script automatici o revisioni periodiche delle statistiche.