Qualcuno ha metriche sull'utilità di Unit Testing formale?

https://stackoverflow.com/questions/333922

22-07-2019
|

Domanda

Qualcuno ha metriche sull'utilità di Unit Testing formale? Vedo molta attenzione agli strumenti di unit testing ed ero curioso di sapere perché?

Ho interrotto i test formali unitari oltre 5 o 6 anni fa e il guadagno netto in termini di produttività sembra piuttosto elevato. Ho interrotto i test delle unità perché ho notato che non ha mai catturato nulla, per non parlare di qualcosa di utile. Il tipo di errori rilevati dai test unitari sembra essere prevenibile non bevendo più di 2 bicchieri di vino / birra all'ora (o 2 articolazioni all'ora). Inoltre, i test unitari sembrano creare rischi consentendo allo sviluppatore di pensare che ci sia una certa misura di sicurezza per individuare i propri errori.

Faccio un test per assicurarmi che il codice funzioni come dovrebbe, ma non utilizzo alcuno strumento. Ho testato in base alle modifiche apportate. Il mio tasso di errore di produzione per il nuovo codice è circa zero. Il mio tasso di errore per le modifiche al codice è di circa 2-3 bug al trimestre. Le misure di cui sopra si basano su 4 applicazioni di produzione che sviluppo / supporto.

Soluzione

Ecco un thread che ha alcune ricerche sull'approccio TDD Ricerca su TDD

Esistono prove concrete del ROI dell'unità test?

Altri suggerimenti

Riconosco la tua superiorità come essere umano e programmatore.

Tuttavia, sono un semplice idiota, e senza Python unittest, sarei perso.

Non posso refactoring senza unit test, ci vuole solo troppo pensiero.

Riesco a malapena a codificare senza unit test, è troppo difficile essere assolutamente sicuri di aver capito assolutamente ogni sfumatura.

I test unitario perché sono un idiota. Dal momento che non si commettono errori, chiaramente non è necessario un test unitario. Ti saluto.

Modifica. Per me, i test unitari non riguardano metriche o costi. Non ho bisogno di esperimenti randomizzati e controllati per mostrarmi il valore. Non posso lavorare senza di loro. In effetti, mi rifiuto di lavorare senza di loro. Allo stesso modo, non funzionerò senza un compilatore, un editor di testo o un controllo del codice sorgente; Non lavorerò senza requisiti; Mi rifiuto di programmare senza prima fare design.

Non vedo i test unitari come sostituti dei test tradizionali, ma piuttosto come un passo in più per garantire la correttezza del codice. Alcune aree particolari in cui trovo utili i test unitari sono:

Durante il refactoring / modifica del codice esistente. I test unitari verificheranno che almeno quei casi continuino a funzionare come previsto. Più test hai, più puoi essere sicuro che le modifiche al codice non hanno interrotto il codice esistente.
Quando si inviano segnalazioni di bug. Avere un test unitario che espone un bug è un ottimo modo per dimostrare il bug E sapere quando è stato corretto.
Un mezzo per progettare interfacce. Hai del codice di prova con cui verificare le interfacce.

Probabilmente alcuni altri di cui ho dimenticato :-P

PS: come fai a sapere di non fare bug? Non penso di introdurre bug nel codice su cui lavoro, ma questo non lo rende certo. IMHO, è ingenuo pensare che il tuo codice sia privo di bug.

(Per quanto riguarda i test unitari, se sai che il tuo codice può contenere bug - e direi che la maggior parte del codice lo fa - non vorresti usare tutti i mezzi possibili per catturarli?)

Ecco un white paper sul test unitario che potrebbe aiutarti:

Ma, Martin Fowler , la prova aneddotica a supporto dei test unitari e TDD è travolgente, ma non è possibile misurare la produttività.

Il test unitario è buono perché puoi cambiare una parte e sapere se da qualche altra parte ha modificato qualcosa. Alcune persone sono "innamorate" con Unit Testing e dovrebbero calmare i loro dodici. Credo nel Unit Testing ma le persone che cercano di nascondere tutto sono pericolose per le persone che non effettuano il test unitario.

Non ho alcuna metrica su cui puntare, ma penso che l'aumento della popolarità sia dovuto al fatto che il resto di noi ha avuto un'esperienza che è l'opposto della tua. :)

Con i test unitari, posso correggere i bug nel codice di produzione e installare la nuova versione entro l'ora in cui il bug è stato trovato e posso essere sicuro che la nuova versione non è peggiore di quella che avevamo prima, perché i test mi dicono così. Potrebbe essere meglio, però.

Mi danno una filigrana più bassa al di sotto della quale la qualità del mio codice non potrà mai affondare. Mi permettono di tenere traccia del quadro più ampio e fare in modo che i test trovino i piccoli errori che tendo a fare. Mi permettono anche di sviluppare uno stile molto rilassato.

Da quando provo, tendo a consegnare in tempo, la mia qualità del codice è migliorata molto e il risultato di solito funziona come previsto. Inoltre, sono molto più veloce poiché posso tagliare angoli che sarebbero troppo pericolosi per provare se non avessi i test.

Detto questo, anche io non ho numeri concreti né conosco alcuna fonte nonostante il fatto che sto facendo unit test e TDD da anni. Il mio amore per i test si basa sul passaparola puro e sull'esperienza personale.

Ho scoperto che i test unitari mi aiutano ad aggiungere nuove funzionalità. In questo scenario ero preoccupato che ciò che stavo aggiungendo avrebbe rotto qualcosa in qualche parte remota dell'applicazione. Ma con i test unitari appropriati so se ho rotto qualcosa nel momento in cui eseguo i test.

Ecco una discussione interessante sull'utilità di unit test.

Se non ti piacciono i test unitari, un altro concetto che potresti voler esaminare è Design by Contract . Il che afferma sostanzialmente che se determinate condizioni di input sono soddisfatte, ci sarà un output garantito in base al contratto.

Sono un responsabile dello sviluppo. Per la mia organizzazione, la configurazione e la migrazione per non essere implicati comportavano alcuni costi di installazione e aumentavano i nostri tempi di sviluppo. Ad alcuni sviluppatori è piaciuto, altri hanno pensato che fosse una perdita di tempo.

Non si è verificato un notevole cambiamento nei tassi di errore, ma forse è troppo presto per dirlo.

Dal mio punto di vista, penso che aiuti gli sviluppatori junior che non sono sicuri del loro lavoro, ma per gli sviluppatori senior sembra rallentarli: è un'altra cosa da tenere aggiornati. Non sono sicuro se continueremo a usarlo, torneremo ai nostri vecchi modi (test di unità ad hoc) o permettere agli sviluppatori di fare una scelta personale.

Esistono diversi strumenti che misurano la copertura del codice con unit test. Sono una parte essenziale insieme al test unitario per garantire che il codice non sia solo testato, ma completamente testato.

Tutto il resto è solo pura magia;)

Se vuoi refactoring il codice, per definizione hai bisogno di un modo per dire se le modifiche hanno rotto il codice. In mancanza di una visione divina, trovo che il test unitario sia uno strumento abbastanza buono, ma ymmv.

In particolare, ho ottenuto molti vantaggi utilizzando Test Driven Development (TDD) con C ++ su un'enorme applicazione server monolitica.

Quando lavoro su un'area di codice, per prima cosa mi assicuro che quell'area sia coperta da test prima di cambiare o scrivere un nuovo codice.

In questo caso d'uso ho enormi guadagni in termini di produttività.

Per compilare ed eseguire il mio test: 10 secondi.
Per compilare, eseguire e testare manualmente l'intero server: min 5 minuti.

Ciò significa che sono in grado di iterare un'area di codice molto rapidamente e testare completamente solo quando è necessario.

Oltre a questo ho anche utilizzato i test di integrazione che richiedono più tempo per essere compilati ed eseguiti, ma esercito solo la specifica funzionalità che mi interessa.

Ho una certa simpatia per quello che stai dicendo. La mia esperienza è simile in quanto i miei nuovi bug raramente vengono catturati dai test unitari. In ogni caso, i test unitari vengono modificati dopo che il bug è stato trovato per assicurarsi che non riappaia.

Dove i test unitari mi hanno aiutato è nella progettazione delle mie classi (Java). Ho spesso rifattorizzato le classi per renderle testabili (ad esempio la rimozione di singoli) che, penso, ha migliorato il design generale. Per me, questo è un motivo sufficiente per usarli.

Nella mia esperienza, Unit Testing mi ha aiutato con le seguenti cose:

Ora posso dedicare tutta la mia attenzione al blocco di codice / funzione / classe che sto scrivendo senza preoccuparmi di nient'altro, perché so che se faccio qualcosa di stupido o causa un effetto collaterale i miei test mi diranno
Posso riformattare le cose sapendo che non sto rompendo le cose
Sono sicuro che la mia app funziona come previsto
Prima di una versione non controllo manualmente ogni singola funzionalità per confermare che l'app funzioni ancora,
Sono sicuro che la mia applicazione è sempre stabile in un certo livello

Tuttavia, questo è un po 'correlato a me, dato che sono davvero pessimo riguardo a "gestire più cose alla volta". e "messa a fuoco". Pertanto Unit Testing funziona per me e letteralmente salva la mia giornata così tante volte, dove ho introdotto una nuova funzionalità e ha rotto alcune vecchie funzionalità.

Se questo non è il tuo caso, non usarlo. Se hai ancora gli stessi risultati, prestazioni e qualità con la stessa quantità di bug, ciò significa che non hai bisogno di test unitari. Oppure è necessario rivedere le metodologie di test delle unità.

P.S. Sulla base del tuo tasso di bug e di ciò che hai detto sembri comunque un genio (supponendo che si tratti di progetti medi o grandi), quindi direi che non usi i Test unitari, sembra che tu stia andando bene. Ma per il resto del mondo che non sono geniali come me consiglio vivamente Unit Test perché ha funzionato per me.

Non so chi sei, ma ho appena verificato due correzioni per due coredump creati da modifiche nel codice esistente che i miei test di unità hanno rilevato. E ho appena avuto un grosso problema di produzione che sarebbe stato colto da un test unitario se avessi avuto più fiducia nei suoi risultati (i nostri unittests sono un po 'più dal punto di vista funzionale di quanto vorrei ammettere).

Mi sembra che il Unit Testing formale con i popolari strumenti di test sia più o meno simile alla sicurezza negli aeroporti degli Stati Uniti.

Fornisce l'illusione della sicurezza
Fa stare bene le persone
È molto scomodo (estremamente scomodo se hai la pelle di colore sbagliata)
Le persone agitano rabbiosamente il pugno verso di te se lo critichi ...
Queste stesse persone rimarranno confuse quando il loro processo fallirà e salteranno sul carro della band successiva ...

Penso che le persone abbiano diverse prospettive sul software. A mio avviso, il software è un mezzo per fare soldi (si spera fornendo maggiori entrate o risparmiando denaro). Ho visto i post per TDD che è il più vicino che vedo come un modo scientifico per rispondere alla domanda, ma la metodologia manca di rigore scientifico. Nessuno degli articoli specificati aveva una linea di base o un metodo alternativo abbastanza contrastato.

Suppongo che i fan dei test unitari formali continueranno a sentirsi sicuri nei loro modi. Continuerò a scrivere le mie specifiche su un pezzo di carta e metterò la ciotola ai piedi della mia statua di Sant'Antonio e dirò una preghiera. Chi può dire in che modo sia più efficace, ma la mia strada è sicuramente positiva ... Forse scriverò un white paper a riguardo.

Ricorda l'aumento della popolarità dei tagli e dei vestiti degli anni '70 e '80 ... che non ha funzionato così bene per quelli di noi che hanno vissuto in quei decenni.

I test unitari formali richiedono notevoli sforzi e sforzi per essere mantenuti. Immagino che ci vuole il 20-50% del tempo necessario per sviluppare effettivamente il software. Quello che chiedo è il prezzo noto di aggiungere il 20-50% di spese generali a ogni sforzo di sviluppo, è il guadagno degno di nota e / o dimostrabile.

Non effettuando test unitari formali, stai forzando lo sviluppatore a pensare attraverso le cose appropriate da testare. Lo sviluppatore assume una maggiore proprietà del prodotto.

Il test formale dell'unità suona come il succo di olio di serpente ... Tutti e suo fratello dicono che è buono, utile, bello, ecc., ma non c'è stato un processo controllato randomizzato per dimostrare che in realtà risparmia tempo o denaro. Tutte le risposte finora sono testimonianze soggettive.

Quello che vorrei sapere è se esiste un software manager in grado di dimostrare una maggiore produttività (o anche una qualità superiore) dopo l'introduzione del test unitario.

lol - il facantious rant di S.Lott è la risposta più votata ... Dato che questo forum è anonimo (per me comunque), il tuo rispetto non è quello che sto cercando. Mi considererei a malapena al di sopra del mediocre. Ho lavorato con sviluppatori eccezionali ... quei ragazzi in genere non fanno nemmeno test di base del loro codice - sanno solo che funzionerà.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow