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

some of them suggest me that it's not necessary

Bene, in senso stretto hanno ragione: test, revisioni del codice, controllo del codice sorgente ecc. non sono strettamente necessari . Solo pochissimi sviluppatori ragionevoli lavorano senza questi a lungo termine. Molti di noi hanno imparato (spesso nel modo più duro, dai propri errori) perché queste sono le migliori pratiche.

and it has a very little benefit.

Questo è not true 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.

They also claim that only few companies do unit-test with production software.

Questo potrebbe essere vero (anche se nella mia esperienza sempre meno), ma non ha nulla da dire sul valore dei test unitari. In contrasto con questo vecchio scherzo "Merda è buono - 50 miliardi di mosche non possono essere sbagliate!" ; -)

did you apply unit-test at your work and what do you get from it? (e.g. better code quality, reduce time in long term etc.)

Ho applicato i test unitari nel mio lavoro, ogni volta che era possibile, per oltre 10 anni. Quella sensazione di sicurezza nel mio codice, sapendo che funziona - e posso dimostrarlo sempre, ovunque, in pochi secondi, ancora e ancora, al contrario di credere in esso - non ha prezzo. Mi dà il coraggio di ridefinire il mio codice, migliorarne il design o correggere bug, senza il timore di rompere le funzionalità esistenti. Non tornerei mai indietro a quei vecchi tempi di "code and pray".

Io li svendo, ma non (o pochi) al lavoro

I principali vantaggi del testing che ottengo sono, che il refactoring è molto più semplice e che la regressione (cioè la reintroduzione di errori già corretti) viene notata.

Test di vita con "la build": controlli il software con test in esecuzione e non esegui il check-in finché tutti i test non sono in esecuzione con la tua modifica.

Quindi, secondo la mia esperienza, scrivere prove è quasi inutile se fatto in un modo da lupo solitario. Quando devi sempre aggiustare i tuoi test per tener conto delle modifiche apportate dagli altri, quando i test possono essere cancellati dai tuoi colleghi (è successo nei miei precedenti lavori) perché "non mi permettono di distribuire", ecc. Sono solo lavori extra con i benefici immediatamente bruciati dal resto della squadra.

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

Ma in una squadra che crede onestamente che "solo poche aziende testano automaticamente il loro codice" e sono convinte che siano comunque una perdita di tempo, sembra esserci poca speranza di guadagnare i benefici, ma una grande possibilità che voi sarà responsabile della "perdita di tempo" quando segnala errori.

La migliore possibilità di introdurre test sarebbe un piccolo progetto sotto la tua esclusiva responsabilità. Lì avresti l'opportunità di brillare e di 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 spesso e senza mente su casi banali in cui un'indagine superficiale del codice rivela che funzionerà a prescindere da cosa. Ad esempio:

def add(x, y)
  x + y
end

Insieme a una dozzina di test per assicurarsi che l'aggiunta funzioni effettivamente per casi d'uso scelti in modo arbitrario. Duh ...

La premessa generale alla base del testing delle unità è: se il tuo codice non contiene bug, è perché non hai testato abbastanza. Ora, quando scrivere i test unitari appropriati. Risposte:

1. Durante i test
2. Quando esegui il debug
3. Mentre stai sviluppando cose davvero complicate

Esaminiamo ciascuno di essi, supponendo che tu stia sviluppando una specie di web app.

Scrivi del codice per nuove funzionalità, e dovrebbe funzionare abbastanza bene ora. Quindi protendi il tuo browser e verifica che funzioni 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: per testare le funzionalità di alto livello.

Quindi scopri un bug (che non perde mai niente?). Questo ci porta al secondo punto. Torna al codice e inizia a seguire i passaggi. Mentre lo fai, scrivi i test unitari nei punti di interruzione chiave in cui avere dati coerenti e corretti è fondamentale.

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

In questo tipo di ambiente spinoso, in genere desideri automatizzare molto i test. Quindi scrivi script per automatizzare la generazione di dati di test ed esegui un carico di unità di test su questi dati di test. Una cosa fondamentale da non perdere di vista mentre fai questo, è che devi anche scrivere dei test unitari per il tuo generatore di test di unità.

Bottom line: unit test, sicuramente si. Ma risparmia te stesso sulle funzionalità di base - fino a quando non ne hai effettivamente bisogno per il debug, o assicurandoti che alcune funzionalità pelose funzionino correttamente (incluso, 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 nulla.

È possibile scrivere test di unità o sperare di scrivere test di integrazione di livello superiore o test di accettazione.

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 che le unità funzionano effettivamente. Senza test unitari, come fai a sapere che le unità funzionano? Come puoi eseguire il debug di un test di integrazione se non sai che le singole unità integrate funzionano effettivamente?

I test di accettazione, in modo simile, dipendono da tutti i pezzi e le parti funzionanti. Come puoi sapere che pezzi e parti funzionano senza una serie di test unitari?

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

Ciò rende la verifica delle unità una necessità logica. Non c'è altra scelta.

Uso i test unitari per tutto ciò che scrivo, e non permetto a nessun codice test non testato di passare in rassegna senza un caso di test. (Ma mi manca uno strumento di copertura, quindi devo ragionare sulla copertura dei test. Una cosa alla volta ...)

È piuttosto 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 tutta la mia base di codice funziona.
• La capacità di migliorare il mio codice: posso ristrutturare il mio codice - refactarlo - sapendo che dopo la ristrutturazione non ho infranto nulla.

Il test unitario è una disciplina. Poiché non è necessario che il codice funzioni, viene spesso scartato.

È, tuttavia, un metodo collaudato che porta a un codice robusto e meno buggato. Non penso di doverti spiegare i benefici, come hai già menzionato. Se osservi alcuni dei principali progetti open source, siano essi librerie javascript, framework full-stack o applicazioni monouso, tutti usano il test dell'unità.

Ho il sospetto che i tuoi colleghi che consigliano di non usarlo non siano programmatori. Se lo sono, beh diciamo solo che non ci sono molte persone che apprezzo 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 un lungo script di codice procedurale, ma sappiamo tutti che vorresti averlo scritto in stile orientato agli oggetti quando hai bisogno di rifattorizzarlo dopo 2 anni.

Lo stesso vale per i test unitari. Se si scrivono test unitari per parti critiche nella propria applicazione, è possibile assicurarsi che funzioni come previsto, sempre, anche dopo il codice di refactoring. Magari codifichi così bene che non hai mai un bug di regressione. Ma se non lo fai, o un nuovo programmatore si unisce al tuo team, vuoi assicurarti che i bug del passato non si ripetano. Penso che anche il tuo capo sarebbe contento di questo, invece di dover presentare una segnalazione di bug che pensava fosse stata risolta mezzo anno fa.

I test unitari richiedono un linguaggio amichevole per test unitari, un design amichevole ai test unitari e un problema di test unitario.

Il C ++, il design multithread e la GUI saranno un incubo e la copertura del problema sarà spaventosa.

.NET, assembly dll single-thread riutilizzabile, la pura logica computazionale sarà un gioco da ragazzi.

Ne vale la pena, non posso davvero dire.

Rifattori molto? Vedete "stupidi bug" come "off by one" nel vostro codice molto?

Qualunque cosa tu faccia, non essere quel ragazzo che critica gli altri con "non hai test unitari, quindi fai schifo". Se i test ti aiutano, fallo, se no, non è come se fossero una pallottola d'argento.

I voglio , ma ho avuto la sfortuna di lavorare quasi interamente a società a cui non mi interessa della qualità, e sono più concentrate nel mettere insieme spazzatura che un po 'tipo forse-se-tu-strabico funziona. Ho menzionato i test unitari e ottengo un "Huh?" tipo di look (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 in una compagnia 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 veramente.

Mi sono dilettato in prove unitarie in progetti fittizi usa e getta, ma non ho mai avuto la testa su TDD / BDD in piena regola, e il fatto di non avere un mentore che possa aiutarlo rende molto più difficile da fare correttamente.

Li usiamo. Un grande vantaggio che otteniamo è il controllo del quadro di test unitario per le perdite di memoria e errori di allocazione . A volte il problema si trova nel codice di test dell'unità, ma spesso è nel codice di produzione.

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

I test unitari (dovrebbero) anche esegui molto rapidamente e possono essere eseguiti come parte della tua integrazione continua dopo ogni singolo commit, e anche dagli sviluppatori prima di impegnarsi. Abbiamo oltre 1.000 che richiedono 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. Ovviamente, i test unitari non sono l'unico test che dovresti fare, ma a livello di codice a grana fine 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 copertura della funzione del 100%, il che sarebbe molto difficile da ottenere senza test unitari.

Direi che i test unitari aggiungono valore, ma io non sono un grande discepolo del TDD. Trovo il massimo vantaggio con i test unitari quando eseguo i calc, o qualsiasi tipo di motore in realtà e quindi le classi di utilità, i test unitari sono molto utili allora.

Preferisco test di integrazione automatizzati per i blocchi più dipendenti dai dati, ma tutto dipende, io sono nel business dei dati, così tanti errori sono più correlati ai dati nel nostro ambiente di qualsiasi altra cosa, e per questo i test di integrazione automatica funzionano bene . Controllo dei dati prima e dopo e generazione di rapporti di eccezione da tali test.

Quindi i test unitari apportano realmente un valore aggiunto, specialmente se l'unità che si sta testando può essere fornita con tutti gli input necessari e funzionare autonomamente con l'input specificato. Anche nel mio caso i motori di calcolo e le classi di utilità sono esempi perfetti di questi.

Costi: più lento al codice, curva di apprendimento, inerzia dello sviluppatore

Vantaggi: In genere mi sono trovato a scrivere codice migliore quando ho provato per la prima volta - SOLID wise ...

Ma IMHO, il più grande beneficio che io penso, è l'affidabilità in sistemi più grandi che cambiano frequentemente. Un buon test unitario salverà il tuo sedere (fatto mio) quando rilascerai più versioni e potrai eliminare una grossa fetta di costi associati ai processi di QA manuale. Non garantirà ovviamente il codice senza errori, ma prenderà alcuni difficili da prevedere. Nei sistemi complessi di grandi dimensioni, questo può essere davvero un grande vantaggio.

Faccio qualche test unitario al lavoro quando ne ho la possibilità, e cerco di convincere i miei colleghi a fare lo stesso.

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

Dove ho visto il vero vantaggio di codificare i Test delle unità e fare dell'esecuzione del test delle unità parte del processo di compilazione giornaliero era su un progetto con più di 30 sviluppatori che lavorano in 3 diversi continenti. Nei casi in cui il test unitario è davvero brillante, quando qualcuno cambiava sottilmente una classe che manteneva senza capire come la gente stesse usando quella classe. Invece di aspettare che il codice colpisse il gruppo di test, ci fu un riscontro immediato quando i test unitari di altre persone iniziarono a fallire come conseguenza del cambiamento. [Ecco perché tutti i test unitari devono essere eseguiti di routine, non solo quelli che hai scritto per il tuo codice.]

Le mie linee guida per il test delle unità sono:

1. Verifica tutte le condizioni a cui puoi pensare per il tuo codice, inclusi input, limiti e così via.
2. Tutti i test delle unità per tutti i moduli devono essere eseguiti regolarmente (vale a dire come parte delle build notturne)
3. Controlla i risultati del test unitario!
4. Se qualcuno trova un bug nel codice che ha superato i test, scrivi un nuovo test per questo!

Recentemente ho imparato il TDD e ho trovato che è molto utile. Fornisce maggiore sicurezza sul fatto che il mio codice si comporti come mi aspetto. Insieme a rendere ogni ri-factoring che desidero fare più facile. Ogni volta che viene rilevato un bug, puoi assicurarti che attraverso il test non si visualizzi più.

La parte più difficile è scrivere test di unità buoni .

È un buon punto di riferimento per il tuo codice.