Usi unit test al lavoro? Quali benefici ottieni da loro? [chiuso]

Avevo programmato di studiare e applicare i test unitari al mio codice, ma dopo aver parlato con i miei colleghi, alcuni di loro mi hanno suggerito che non è necessario e ha un beneficio molto piccolo. Sostengono inoltre che solo poche aziende eseguono test di unità con software di produzione.

Sono curioso di sapere come le persone hanno applicato i test unitari sul lavoro e quali vantaggi ottengono dall'utilizzarli, ad esempio una migliore qualità del codice, tempi di sviluppo ridotti a lungo termine, ecc.

alcuni mi suggeriscono che non è necessario

Bene, in senso stretto hanno ragione: anche i test, le revisioni del codice, il controllo del codice sorgente ecc. Non sono strettamente necessari . Solo che pochissimi sviluppatori sensibili funzionano senza questi a lungo termine. La maggior parte di noi ha imparato (spesso nel modo più duro, dai propri errori) perché queste sono le migliori pratiche.

e ha un beneficio molto piccolo.

Questo non è vero nella maggior parte dei casi. Cioè, se stiamo parlando di software di produzione che dovrebbe essere in uso - quindi in manutenzione - per gli anni a venire.

Sostengono inoltre che solo poche aziende effettuano test unitari con software di produzione.

Questo può essere vero (anche se nella mia esperienza sempre meno), ma non ha nulla da dire sul valore del test unitario. Contrariamente a questo il vecchio scherzo "Merda è buona - 50 miliardi di mosche non possono essere sbagliate!" ;-)

hai applicato unit-test sul tuo lavoro e cosa ne ottieni? (ad es. migliore qualità del codice, riduzione dei tempi a lungo termine ecc.)

Applico test unitari nel mio lavoro, ogni volta che era possibile, da oltre 10 anni. Quella sensazione di fiducia nel mio codice, sapendo che funziona - e posso dimostrarlo sempre e ovunque, in pochi secondi, ancora e ancora, invece di crederci - non ha prezzo. Mi dà il coraggio di riformattare il mio codice, migliorarne il design o correggere i bug, senza il timore di violare le funzionalità esistenti. Non tornerei mai più ai vecchi tempi del "codice e pregare".

Faccio unittest, ma non (o pochi) al lavoro

I principali vantaggi dei test che ottengo sono che il refactoring è molto più semplice e che si nota la regressione (ovvero la reintroduzione di errori già corretti).

Il test vive con 'the build': controlli il software con i test in esecuzione e non esegui il check-in fino a quando tutti i test non vengono eseguiti con la tua modifica.

Quindi, secondo la mia esperienza, scrivere test è quasi inutile se fatto in modo da lupo solitario. Quando devi sempre correggere i tuoi test per far fronte alle modifiche apportate dagli altri, quando i test possono essere cancellati dai tuoi colleghi (cosa accadeva nei miei precedenti lavori) perché "non mi lasciano distribuire", ecc. Sono solo lavori extra con i benefici immediatamente bruciati dal resto della squadra.

Quando tutto il team è d'accordo (e, in un team di 1 che è facile), nella mia esperienza, i test sono un grande vantaggio per la qualità, lo stile e la solidità del Progetto.

Ma in un team che crede onestamente che "solo poche aziende testano il loro codice automaticamente" e sono convinte che siano comunque una perdita di tempo, sembra che ci siano poche speranze di guadagnare i benefici, ma una grande possibilità che tu possa fare responsabile della "perdita di tempo" quando si segnalano errori.

La migliore possibilità di introdurre test sarebbe un piccolo progetto sotto la tua esclusiva responsabilità. Lì avresti l'opportunità di brillare e dimostrare il valore dei test.

Tendo a schierarmi con i tuoi colleghi, ma solo fino a un certo punto.

Il problema con i test unitari è che sono scritti frequentemente e inconsapevolmente su casi insignificanti in cui un'indagine rapida del codice rivela che funzionerà a prescindere. Per esempio:

def add(x, y)
  x + y
end

Insieme a una dozzina di test per assicurarsi che l'aggiunta funzionerà davvero per casi d'uso scelti arbitrariamente. Duh ...

La premessa generale alla base del test unitario è: se il tuo codice non contiene bug, è perché non hai testato abbastanza. Ora, quando scrivere test unitari adeguati. risposte:

1. Quando stai testando
2. Quando esegui il debug
3. Mentre stai sviluppando cose davvero difficili

Esaminiamo ciascuno di essi, supponendo che tu stia sviluppando un qualche tipo di app web.

Scrivi del codice su nuove funzionalità e dovrebbe funzionare abbastanza bene ormai. Quindi raggiungi il tuo browser e verifichi che funzioni testando più intensamente, giusto? Bzzzt! ... Risposta sbagliata. Scrivi un test unitario. Se non lo fai ora, probabilmente non lo farai mai. E questo è uno dei luoghi in cui i test unitari funzionano molto bene: testare funzionalità di alto livello.

Quindi scopri un bug (a chi non manca mai nessuno?). Questo ci porta al punto due. Ti immergi nuovamente nel codice e inizi a seguire i passaggi. Mentre lo fai, scrivi i test unitari nei punti di interruzione chiave in cui è fondamentale disporre di dati coerenti e corretti.

L'ultimo punto è il contrario. Stai progettando alcune funzionalità pelose che comportano un sacco di meta-programmazione. Genera rapidamente un albero decisionale con migliaia di scenari potenziali e devi assicurarti che ciascuno di essi funzioni. Quando si scrivono cose del genere, un semplice cambiamento qui o là può avere conseguenze inimmaginabili lungo la catena alimentare. Supponiamo che tu stia progettando un'implementazione MPTT usando i trigger SQL, in modo che possa funzionare con istruzioni a più righe.

In questo tipo di ambiente spinoso, in genere vorrai automatizzare fortemente i tuoi test. Quindi scrivi script per automatizzare la generazione di dati di test ed esegui un carico di test unitari su questi dati di test. Una cosa cruciale da non perdere durante questa operazione è che devi anche scrivere unit test per il tuo generatore di unit test.

Bottom line: unit test, sicuramente sì. Ma risparmia quelli sulla funzionalità di base - fino a quando non ne avrai realmente bisogno per il debug o assicurandoti che alcune funzionalità pelose funzionino correttamente (compresi, in quest'ultimo caso, i test stessi).

Tutto il codice deve essere testato. Non c'è scelta al riguardo.

Il codice non testato è inutile: non ci si può fidare di fare nulla.

Puoi scrivere test unitari o sperare di scrivere test di integrazione o test di accettazione di livello superiore.

I test unitari sono più facili da scrivere, più facili da eseguire il debug e più facili da gestire.

I test di integrazione si basano su ipotesi sul funzionamento effettivo delle unità. Senza test unitari, come fai a sapere che funzionano? Come si può eseguire il debug di un test di integrazione se non si conosce il funzionamento effettivo delle singole unità?

I test di accettazione, allo stesso modo, dipendono da tutti i pezzi e le parti funzionanti. Come puoi sapere se i pezzi funzionano senza avere una serie di test unitari?

Il test è obbligatorio. Tutti i test di livello superiore dipendono dalle unità effettivamente funzionanti.

Ciò rende l'unità test una necessità logica. Non c'è altra scelta.

Uso i test unitari per tutto ciò che scrivo e non lascio passare il codice non testato senza un test case. (Ma mi manca uno strumento di copertura, quindi devo ragionare sulla copertura del test. Una cosa alla volta ...)

È abbastanza semplice: se non riesci a dimostrare che il tuo codice funziona (e quale modo migliore di una specifica eseguibile sotto forma di test?), Allora non funziona .

Questo mi dà:

• Tranquillità: il mio server CI mi dice che tutto il mio codebase funziona.
• La capacità di migliorare il mio codice: posso ristrutturare il mio codice - riformattarlo - sapendo che dopo la ristrutturazione non ho rotto nulla.

I test unitari sono una disciplina. Poiché non è necessario che il codice funzioni, viene spesso scartato.

È, tuttavia, un metodo collaudato che porta a codice robusto e meno buggy. Non credo di doverti spiegare i vantaggi, come hai già menzionato. Se guardi ad alcuni dei principali progetti open source, siano essi librerie javascript, framework full-stack o applicazioni monouso, usano tutti i test unitari.

Sospetto che i tuoi colleghi che raccomandano di non usarlo non siano programmatori. Se lo sono, beh, diciamo solo che non ci sono molte persone che apprezzo di più di persone come Martin Fowler o Kent Beck ;).

Come la maggior parte delle migliori pratiche, i vantaggi sono a lungo termine, è necessario investire un po 'di tempo in esso. Potresti scrivere una lunga sceneggiatura di codice procedurale, ma sappiamo tutti che vorresti averlo scritto in uno stile orientato agli oggetti quando devi rifattorarlo dopo 2 anni.

Lo stesso vale per i test unitari. Se si scrivono unit test per le parti critiche nella propria applicazione, è possibile assicurarsi che funzioni sempre come previsto, anche dopo il refactoring del codice. Forse codifichi così bene da non avere mai un bug di regressione. Ma se non lo fai, o un nuovo programmatore si unisce alla tua squadra, vuoi assicurarti che i bug del passato non si ripetano. Penso che anche il tuo capo sarebbe contento di questo, al contrario di dover presentare una segnalazione di bug che pensava fosse risolta sei mesi fa.

I test unitari richiedono un linguaggio amichevole test unitario, un design intuitivo test unitario e un problema amichevole test unitario.

C ++, design multithread e GUI saranno un incubo e la copertura dei problemi sarà spaventosa.

.NET, assembly dll riutilizzabile a thread singolo, pura logica computazionale sarà un gioco da ragazzi.

Ne vale la pena, non posso davvero dirlo.

Rifattori molto? Vedi "stupidi bug" come "off by one" nel tuo codice molto?

Qualunque cosa tu faccia, non essere quel tipo che critica gli altri con "non hai test unitari, quindi fai schifo". Se i test ti aiutano, fallo, in caso contrario, non è come se fossero un proiettile d'argento.

Lo voglio , ma ho avuto la sfortuna di lavorare quasi interamente in aziende che non si preoccupano della qualità e sono più concentrate nel buttare insieme spazzatura che in qualche modo funziona come se fosse uno strabismo. Ho citato test unitari e ho ricevuto un "Huh?" tipo di aspetto (lo stesso aspetto che ottengo quando menziono i principi SOLID , o ORM, o modelli di progettazione oltre la "classe con tutti i metodi statici", o seguendo le convenzioni di denominazione .NET). Sono sempre stato presso un'azienda che ha capito quella roba, e sfortunatamente era un contratto a breve termine e il dipartimento è stato tagliato per tagliare i costi, quindi non c'era abbastanza tempo per imparare davvero.

Mi sono dilettato in test unitari in progetti fittizi usa e getta, ma non ho davvero avuto la testa attorno a TDD / BDD in piena regola, e non avere un mentore che possa aiutarlo rende molto più difficile fare correttamente.

Li usiamo. Un grande vantaggio che otteniamo sono i controlli del framework di unit test per perdite di memoria e errori di allocazione . A volte il problema è nel codice di unit test stesso, ma spesso è nel codice di produzione.

È un ottimo modo per trovare quelle cose che mancano in una revisione del codice.

Anche i test unitari (dovrebbero) vengono eseguiti molto rapidamente e possono essere eseguiti come parte della tua continua integrazione dopo ogni singolo commit, e anche dagli sviluppatori prima del commit. Abbiamo oltre 1.000 che impiegano meno di 20 secondi per funzionare.

Confronta con oltre 40 minuti per i test di automazione a livello di sistema e ore / giorni per i test manuali. Naturalmente, i test unitari non sono gli unici test che dovresti fare, ma a un livello di codice ben preciso possono aiutare a trovare bug e testare quei casi limite che i test di sistema / integrazione non possono toccare. Il nostro codice deve essere testato con una copertura decisionale superiore al 75% e con una copertura funzionale del 100%, che sarebbe molto difficile da ottenere senza test unitari.

Direi che i test unitari aggiungono valore, ma non sono un grande discepolo TDD. Trovo il massimo beneficio con i test unitari quando eseguo motori di calcolo, o qualsiasi tipo di motore realmente e quindi classi di utilità, quindi i test unitari sono molto utili.

Preferisco i test di integrazione automatizzata per i blocchi più dipendenti dai dati, ma tutto dipende, sono nel settore dei dati, quindi molti errori sono più legati ai dati nel nostro ambiente rispetto a qualsiasi altra cosa, e per questo i test di integrazione automatizzata funzionano bene. Verifica dei dati prima e dopo e generazione di rapporti sulle eccezioni da tali test.

Quindi i test unitari aggiungono davvero valore, specialmente se l'unità che stai testando può essere fornita con tutti gli input di cui ha bisogno e funziona da sola con l'input dato. Anche in questo caso i motori di calcolo e le classi di utilità sono esempi perfetti di questi.

Costi: codice più lento, curva di apprendimento, inerzia degli sviluppatori

Vantaggi: in genere mi sono trovato a scrivere codice migliore quando ho provato prima - SOLID saggio ...

Ma IMHO, il più grande vantaggio che penso, è l'affidabilità in sistemi più grandi che cambiano frequentemente. Un buon test unitario salverà il tuo culo (fatto mio) quando rilasci più versioni e puoi eliminare una grossa fetta di costi associati ai processi manuali di controllo qualità. Ovviamente non garantirà il codice privo di bug, ma ne catturerà alcuni difficili da prevedere. Nei grandi sistemi complessi, questo può essere davvero un grande vantaggio.

Faccio alcuni unit test sul lavoro quando ne ho la possibilità e cerco di convincere i miei colleghi a fare lo stesso.

Non sono religioso a riguardo, ma l'esperienza dimostra che i metodi di utilità e di business che sono stati test unitari sono molto robusti e tendono a presentare pochi o nessun bug durante la fase di test, che alla fine riduce i costi del progetto.

Dove ho visto il vero vantaggio di codificare i test delle unità e rendere l'esecuzione dell'esecuzione dei test delle unità parte del processo di compilazione giornaliera era su un progetto con oltre 30 sviluppatori che lavoravano in 3 diversi continenti. Il punto in cui i test unitari erano davvero brillanti era quando qualcuno cambiava in modo sottile una classe che manteneva senza capire come le persone usavano quella classe. Invece di aspettare che il codice colpisse il gruppo di test, ci fu un feedback immediato quando i test unitari di altre persone iniziarono a fallire a seguito del cambiamento. [Ecco perché tutti i test unitari devono essere eseguiti regolarmente, non solo quelli che hai scritto per il tuo codice.]

Le mie linee guida per i test unitari sono:

1. Metti alla prova ogni condizione che riesci a immaginare per il tuo codice, inclusi input, confini, ecc. Errati
2. Tutti i test delle unità per tutti i moduli devono essere eseguiti regolarmente (ovvero come parte delle build notturne)
3. Controlla i risultati del test unitario!
4. Se qualcuno trova un bug nel tuo codice che ha superato i test, scrivi un nuovo test per questo!

Recentemente ho imparato TDD e trovo che sia molto utile. Dà maggiore sicurezza che il mio codice si comporti come mi aspetto. Oltre a rendere più semplice il factoring che desidero fare. Ogni volta che viene rilevato un bug, durante il test è possibile assicurarsi che non venga più visualizzato.

La parte più difficile è scrivere buoni test unitari.

È un buon punto di riferimento per il tuo codice.