it-swarm.it

Il test unitario vale lo sforzo?

Sto lavorando per integrare i test delle unità nel processo di sviluppo del team su cui lavoro e ci sono alcuni scettici. Quali sono alcuni buoni modi per convincere gli sviluppatori scettici sulla squadra del valore del Test unitario? Nel mio caso specifico aggiungerei test unitari quando aggiungiamo funzionalità o bug corretti. Sfortunatamente la nostra base di codice non si presta a test facili.

573
Ross Fuhrman

Ogni giorno nel nostro ufficio c'è uno scambio che va in questo modo:

"Amico, adoro i test unitari, sono stato in grado di apportare alcune modifiche al modo in cui qualcosa funziona, e quindi sono stato in grado di confermare che non avevo rotto nulla eseguendo di nuovo il test su di esso ..."

I dettagli cambiano ogni giorno, ma il sentimento no. I test unitari e lo sviluppo basato sui test (TDD) hanno così tanti vantaggi personali e nascosti così come quelli ovvi che non puoi davvero spiegare a qualcuno finché non lo fanno da soli.

Ma, ignorandolo, ecco il mio tentativo!

  1. Test unitari consente di apportare rapidamente grandi modifiche al codice. Sai che ora funziona perché hai eseguito i test, quando apporti le modifiche che devi apportare, devi fare in modo che i test funzionino di nuovo. Questo risparmia ore.

  2. TDD ti aiuta a capire quando smettere di scrivere il codice. I tuoi test ti danno la sicurezza di aver fatto abbastanza per ora e possono smettere di fare il tweaking e passare alla prossima cosa.

  3. I test e il codice lavorano insieme per ottenere un codice migliore. Il tuo codice potrebbe essere cattivo/buggy. Il tuo TEST potrebbe essere cattivo/buggy. In TDD stai scommettendo sulla possibilità che entrambi di essere cattivo/bacato siano bassi. Spesso è il test che deve essere corretto, ma è comunque un buon risultato.

  4. TDD aiuta nella stitichezza della codifica. Di fronte a un grosso e scoraggiante lavoro, scrivere i test ti farà muovere rapidamente.

  5. I test unitari ti aiutano a capire veramente il design del codice su cui stai lavorando. Invece di scrivere codice per fare qualcosa, inizi a delineare tutte le condizioni a cui stai sottoponendo il codice e quali risultati ti aspetteresti da ciò.

  6. I test delle unità forniscono un riscontro visivo immediato, a tutti noi piace la sensazione di tutte quelle luci verdi quando abbiamo finito. È molto soddisfacente È anche molto più facile riprendere da dove hai interrotto dopo un'interruzione perché puoi vedere dove sei arrivato - il prossimo semaforo che deve essere riparato.

  7. Contrariamente alle credenze popolari, il test delle unità non significa scrivere il doppio del codice, o la codifica più lentamente. È più veloce e più robusto della codifica senza test una volta capito. Il codice di prova di per sé è di solito relativamente banale e non aggiunge un sovraccarico a quello che stai facendo. Questo è uno che crederai solo quando lo stai facendo :)

  8. Penso che sia stato Fowler a dire: "I test imperfetti, eseguiti frequentemente, sono molto meglio dei test perfetti che non vengono mai scritti affatto". Interpreto questo come darmi il permesso di scrivere test in cui penso che saranno più utili anche se il resto della copertura del mio codice è tristemente incompleto.

  9. I buoni test unitari possono aiutare a documentare e definire cosa si suppone che qualcosa debba fare

  10. I test unitari aiutano a riutilizzare il codice. Esegui la migrazione del tuo codice e i tuoi test sul tuo nuovo progetto. Modificare il codice finché i test non si ripetono.

Un sacco di lavoro in cui sono coinvolto non è un buon test unitario (interazioni utente di applicazioni web ecc.), Ma nonostante ciò siamo tutti testati infetti in questo negozio, e più felici quando abbiamo i nostri test vincolati. Non posso raccomandare l'approccio abbastanza bene.

722
reefnet_alex

Il test delle unità è molto simile ad andare in palestra. Sai che è un bene per te, tutti gli argomenti hanno senso, quindi inizi a lavorare. C'è un Rush iniziale, che è grandioso, ma dopo qualche giorno inizi a chiedermi se valga la pena. Stai trascorrendo un'ora dalla tua giornata per cambiarti e correre su una ruota del criceto e non sei sicuro di ottenere davvero qualcosa di diverso da gambe e braccia doloranti.

Poi, dopo forse una o due settimane, proprio mentre il dolore sta scomparendo, inizia una Grande Scadenza. Devi passare ogni ora del risveglio cercando di ottenere un lavoro "utile", in modo da ritagliare cose estranee, come andare in palestra. Esci dall'abitudine e quando Big Deadline termina, sei di nuovo al punto di partenza. Se riesci a tornare in palestra, ti senti dolorante come la prima volta che sei andato.

Fai qualche lettura, per vedere se stai facendo qualcosa di sbagliato. Cominciate a provare un po 'di disprezzo irrazionale verso tutti i tipi, persone felici che esaltano le virtù dell'esercizio. Ti rendi conto che non hai molto in comune. Non devono guidare per 15 minuti per andare in palestra; ce n'è uno nel loro edificio. Non devono discutere con nessuno dei benefici dell'esercizio fisico; è solo qualcosa che tutti fanno e accetta come importante. Quando si avvicina una Grande Scadenza, non viene detto che l'esercizio non è più necessario di quanto il tuo capo ti chieda di smettere di mangiare.

Quindi, per rispondere alla tua domanda, il test unitario di solito vale la pena, ma la quantità di sforzo richiesta non sarà la stessa per tutti. Il test delle unità può richiedere un enorme sforzo se si ha a che fare con il codice di spaghetti in una società che non ha effettivamente la qualità del codice di valore. (Un sacco di manager canteranno le lodi di Unit Testing, ma ciò non significa che rimarranno per esso quando è importante).

Se stai provando a introdurre il Test delle unità nel tuo lavoro e non vedi tutti i raggi del sole e gli arcobaleni che sei stato portato ad aspettarti, non incolparti. Potresti aver bisogno di trovare un nuovo lavoro per far sì che le Unit Testing funzionino per te.

421
benzado

Il modo migliore per convincere ... trovare un bug, scrivere un test unitario, correggere il bug.

È improbabile che questo particolare bug si ripresenta e puoi provarlo con il tuo test.

Se lo fai abbastanza, gli altri prenderanno piede velocemente.

136
Ed Guiness

thetalkingwalnut chiede:

Quali sono alcuni buoni modi per convincere gli sviluppatori scettici sulla squadra del valore del Test unitario?

Tutti qui si accaparrano un sacco di motivi in ​​modo inequivocabile perché i test unitari sono buoni. Tuttavia, trovo che spesso il modo migliore per convincere qualcuno di qualcosa sia ascoltare al loro argomento e indirizzarlo punto per punto. Se ascolti e li aiuti a verbalizzare le loro preoccupazioni, puoi indirizzare ognuno di essi e convertirli al tuo punto di vista (o almeno lasciarli senza una gamba in piedi). Chi lo sa? Forse ti convinceranno perché i test unitari non sono appropriati per la tua situazione. Non probabile, ma possibile. Forse se pubblichi i loro argomenti contro i test unitari, possiamo aiutarti a identificare i controsensi.

È importante ascoltare e capire entrambi i lati dell'argomento. Se provi ad adottare test unitari troppo zelanti, senza riguardo per le preoccupazioni delle persone, finirai con una guerra religiosa (e probabilmente test unitari davvero inutili). Se lo adotti lentamente e cominci applicandolo dove vedrai il maggior beneficio per il minor costo, potresti essere in grado di dimostrare il valore dei test unitari e avere una migliore possibilità di convincere le persone. Mi rendo conto che non è così facile come sembra - di solito richiede un po 'di tempo e metriche accurate per creare un argomento convincente.

I test unitari sono uno strumento, come tutti gli altri, e dovrebbero essere applicati in modo tale che i benefici (cattura degli errori) superino i costi (lo sforzo di scriverli). Non usarli se/dove non hanno senso e ricorda che sono solo una parte del tuo arsenale di strumenti (ad esempio ispezioni, affermazioni, analizzatori di codice, metodi formali, ecc.). Quello che dico ai miei sviluppatori è questo:

  1. Possono saltare la scrittura di un test per un metodo se hanno una buona argomentazione sul perché non è necessario (ad esempio, troppo semplice per valerne la pena o troppo difficile per valerne la pena) e su come il metodo verrà altrimenti verificato (ad esempio ispezione, affermazioni , metodi formali, test interattivi/di integrazione). Devono considerare che alcune verifiche come le ispezioni e le prove formali sono fatte in un determinato momento e devono quindi essere ripetute ogni volta che il codice di produzione cambia, mentre le prove e le asserzioni unitarie possono essere usate come test di regressione (scritte una volta ed eseguite ripetutamente in seguito ). A volte sono d'accordo con loro, ma più spesso discuterò se un metodo è davvero troppo semplice o troppo difficile da testare.

    • Se uno sviluppatore sostiene che un metodo sembra troppo semplice per fallire, non vale la pena impiegare i 60 secondi necessari per scrivere un semplice test dell'unità a 5 linee? Queste 5 righe di codice verranno eseguite tutte le sere (fai build notturne, giusto?) Per l'anno successivo o più e varrà la pena se anche solo una volta capita di rilevare un problema che potrebbe richiedere 15 minuti o più per identificare e debug. Inoltre, scrivere i facili test unitari fa aumentare il conteggio dei test unitari, il che fa sembrare lo sviluppatore buono.

    • D'altra parte, se uno sviluppatore sostiene che un metodo sembra troppo difficile da testare unitamente (non vale lo sforzo significativo richiesto), forse questa è una buona indicazione che il metodo deve essere diviso o refactored per testare le parti facili. Di solito, questi sono metodi che si basano su risorse insolite come i singleton, l'ora corrente o risorse esterne come un set di risultati del database. Questi metodi di solito devono essere refactored in un metodo che ottiene la risorsa (ad esempio chiamate getTime ()) e un metodo che accetta la risorsa come argomento (ad esempio, prende il timestamp come parametro). Lascio loro saltare il test del metodo che recupera la risorsa e scrivono invece un test unitario per il metodo che ora prende la risorsa come argomento. Di solito, ciò rende la scrittura dell'unità test molto più semplice e quindi utile scrivere.

  2. Lo sviluppatore deve tracciare una "linea nella sabbia" nel modo in cui dovrebbero essere completi i loro test unitari. Più avanti nello sviluppo, ogni volta che troviamo un bug, dovrebbero determinare se test di unità più completi avrebbero colto il problema. Se è così e se tali bug si ripetono ripetutamente, devono spostare la "linea" verso la scrittura di test unitari più completi in futuro (iniziando con l'aggiunta o l'espansione del test dell'unità per il bug corrente). Hanno bisogno di trovare il giusto equilibrio.

È importante rendersi conto che i test unitari non sono un proiettile d'argento e lì è una cosa come test di unità troppo. Nel mio posto di lavoro, ogni volta che impariamo una lezione, sento inevitabilmente "abbiamo bisogno di scrivere più test unitari". Il management annuisce perché è stato sbattuto in testa che "unit test" == "buono".

Tuttavia, dobbiamo comprendere l'impatto di "più test unitari". Uno sviluppatore può scrivere solo ~ N righe di codice alla settimana e devi capire quale percentuale di quel codice dovrebbe essere il codice di test unitario rispetto al codice di produzione. Un posto di lavoro rilassato potrebbe avere il 10% del codice come test unitario e il 90% del codice come codice di produzione, producendo un prodotto con molte (anche se molto buggy) funzionalità (si pensi a MS Word). D'altra parte, un negozio rigoroso con test unitari del 90% e codice di produzione del 10% avrà un prodotto solido e con poche caratteristiche (si pensi "vi"). È possibile che non si sentano mai rapporti su quest'ultimo arresto anomalo del prodotto, ma ciò probabilmente ha a che fare tanto con il prodotto che non vende molto bene quanto con la qualità del codice.

Peggio ancora, forse l'unica certezza nello sviluppo del software è che "il cambiamento è inevitabile". Supponiamo che il negozio severo (test unitari del 90%/codice di produzione del 10%) crei un prodotto che ha esattamente 2 funzionalità (supponendo che il 5% del codice di produzione == 1 funzionalità). Se il cliente arriva e cambia 1 delle funzionalità, la modifica cambia il 50% del codice (45% dei test unitari e il 5% del codice di produzione). Il negozio lax (10% unit test/90% codice di produzione) ha un prodotto con 18 funzionalità, nessuna delle quali funziona molto bene. Il loro cliente rinnova completamente i requisiti per 4 delle loro caratteristiche. Anche se il cambiamento è 4 volte più grande, solo la metà della base di codice viene eliminata (~ 25% = ~ 4,4% test di unità + 20% del codice di produzione).

Il mio punto è che devi comunicare che capisci l'equilibrio tra il test di unità troppo piccolo e troppo - essenzialmente che hai pensato su entrambi i lati del problema. Se riesci a convincere i tuoi pari e/o la tua gestione di ciò, ottieni credibilità e forse hai maggiori possibilità di vincerli.

69
Bert F

Ho giocato con le unità di test un certo numero di volte, e sono ancora convinto che valga lo sforzo dato la mia situazione.

Sviluppo siti Web, in cui gran parte della logica riguarda la creazione, il recupero o l'aggiornamento di dati nel database. Quando ho provato a "deridere" il database per scopi di testing unitario, è diventato molto disordinato e sembrava un po 'inutile.

Quando ho scritto test unitari sulla logica aziendale, non mi ha mai veramente aiutato nel lungo periodo. Poiché lavoro in gran parte sui progetti da solo, tendo a sapere in modo intuitivo quali aree del codice potrebbero essere interessate da qualcosa a cui sto lavorando e io collaudo queste aree manualmente. Voglio consegnare una soluzione al mio cliente il più rapidamente possibile, e spesso i test unitari sembrano una perdita di tempo. Io elencherò le prove manuali e le attraverserò personalmente, ticchettele mentre vado.

Posso vedere che potrebbe essere utile quando un team di sviluppatori sta lavorando a un progetto e aggiornando il codice degli altri, ma anche allora penso che se gli sviluppatori sono di alta qualità, una buona comunicazione e un codice ben scritto dovrebbero spesso essere sufficienti .

38
Ronnie

Una cosa grandiosa dei test unitari è che servono come documentazione per come il tuo codice è destinato a comportarsi. I buoni test sono una specie di implementazione di riferimento, ei compagni di squadra possono guardarli per vedere come integrare il loro codice con il tuo.

31
pkaeding

Il test unitario merita l'investimento iniziale. Da quando ho iniziato a utilizzare il test delle unità un paio di anni fa, ho riscontrato alcuni vantaggi reali:

  • test di regressione rimuove la paura di apportare modifiche al codice (non c'è niente come il caldo splendore di vedere il codice funzionare o esplodere ogni volta che viene apportata una modifica)
  • esempi di codice eseguibile per gli altri membri del team (e te stesso tra sei mesi ..)
  • spietato refactoring - questo è incredibilmente gratificante, provalo!

Gli snippet di codice possono essere di grande aiuto nel ridurre il sovraccarico di creazione di test. Non è difficile creare snippet che consentano la creazione di una struttura di classe e di un dispositivo di test unitario associato in pochi secondi.

26
Jonathan Webb

Dovresti testare il meno possibile!

nel senso, dovresti scrivere solo un numero sufficiente di test unitari per rivelare l'intenzione. Questo spesso viene sorvolato. Il test unitario ti costa. Se apporti delle modifiche e devi cambiare i test, sarai meno agile. Mantieni i test unitari brevi e dolci. Quindi hanno molto valore.

Troppo spesso vedo molti test che non si romperanno mai, sono grandi e goffi e non offrono molto valore, ma finiscono per rallentarti.

25
Keith Nicholas

Non ho visto questo in nessuna delle altre risposte, ma una cosa che ho notato è che ho potuto eseguire il debug molto più velocemente . Non è necessario eseguire il drill down attraverso la tua app con la giusta sequenza di passaggi per arrivare al codice del tuo fixing, solo per scoprire che hai fatto un errore booleano e hai bisogno di rifare tutto da capo. Con un test unitario, puoi semplicemente passare direttamente al codice che stai eseguendo il debug.

23
John MacIntyre

[Ho un punto in cui non riesco a vedere sopra]

"Tutti i test unitari, non lo realizzano necessariamente - FATTO"

Pensaci, scrivi una funzione per magari analizzare una stringa e rimuovere i nuovi caratteri di linea. Come sviluppatore newbie puoi eseguire alcuni casi tramite la riga di comando implementandolo in Main () o creare un front end visivo con un pulsante, legare la tua funzione a un paio di caselle di testo e un pulsante e vedere che succede.

Questo è un test unitario - base e mal messo insieme, ma testate il codice per alcuni casi.

Scrivi qualcosa di più complesso. Genera errori quando si lanciano alcuni casi (test dell'unità) e si esegue il debug nel codice e si esegue il trace. Osservi i valori mentre passi e decidi se hanno ragione o torto. Questo è un test unitario in una certa misura.

L'unità test qui sta davvero prendendo quel comportamento, formalizzandolo in un modello strutturato e salvandolo in modo da poter facilmente rieseguire questi test. Se si scrive un caso di test dell'unità "corretto" piuttosto che un test manuale, ci vuole lo stesso tempo, o forse meno, quando si ha esperienza, e lo si ha a disposizione per ripetere ancora e ancora

21
Chris Gill

Per anni ho cercato di convincere le persone che avevano bisogno di scrivere unit test per il loro codice. Sia che abbiano scritto prima i test (come in TDD) o dopo aver codificato la funzionalità, ho sempre cercato di spiegare loro tutti i vantaggi di avere dei test unitari per il codice. Quasi nessuno è in disaccordo con me. Non puoi essere in disaccordo con qualcosa che è ovvio, e qualsiasi persona intelligente vedrà i benefici del test unitario e TDD.

Il problema con i test unitari è che richiede un cambiamento comportamentale ed è molto difficile cambiare il comportamento delle persone. Con le parole, molte persone saranno d'accordo con te, ma non vedrai molti cambiamenti nel modo in cui fanno le cose.

Devi convincere le persone facendo. Il tuo successo personale attirerà più persone di tutti gli argomenti che potresti avere. Se vedono che non stai solo parlando di unit test o TDD, ma stai facendo quello che predichi e hai successo, le persone cercheranno di imitarti.

Dovresti anche assumere un ruolo di guida perché nessuno scrive il test unitario la prima volta, quindi potresti doverli istruire su come farlo, mostrare loro la strada e gli strumenti a loro disposizione. Aiutali mentre scrivono i loro primi test, rivedi i test che scrivono da soli e mostra loro i trucchi, gli idiomi e gli schemi che hai imparato attraverso le tue esperienze. Dopo un po ', inizieranno a vedere i benefici da soli e cambieranno il loro comportamento per incorporare i test unitari o TDD nella loro cassetta degli attrezzi.

Le modifiche non avverranno durante la notte, ma con un po 'di pazienza, potresti raggiungere il tuo obiettivo.

16
Curro

Una parte importante dello sviluppo basato su test che viene spesso sorvolata è la scrittura di codice verificabile. All'inizio sembra una specie di compromesso, ma scoprirai che il codice testabile è anche in definitiva modulare, manutenibile e leggibile. Se hai ancora bisogno di aiuto per convincere le persone questo è una bella presentazione sui vantaggi del test unitario.

12
Tom Martin

Se il tuo codice base esistente non si presta al collaudo di unità, ed è già in produzione, potresti creare più problemi di quanti ne risolvi cercando di rifattorizzare tutto il tuo codice in modo che sia testabile dall'unità.

Potrebbe essere meglio mettere gli sforzi per migliorare i test di integrazione. C'è molto codice là fuori che è più semplice da scrivere senza un test unitario e se un QA può convalidare la funzionalità rispetto a un documento dei requisiti, allora hai finito. Spediscilo.

Il classico esempio di questo nella mia mente è un SqlDataReader incorporato in una pagina ASPX collegata a GridView. Il codice è tutto nel file ASPX. L'SQL è in una stored procedure. Che cosa testare unitamente? Se la pagina fa quello che dovrebbe fare, dovresti ridisegnarla davvero in più livelli in modo da avere qualcosa da automatizzare?

11
Eric Z Beard

Una delle cose migliori dei test unitari è che il tuo codice diventerà più facile da testare mentre lo fai. Il codice preesistente creato senza test è sempre una sfida perché poiché non erano pensati per essere testati unitamente, non è raro avere un alto livello di accoppiamento tra classi, oggetti difficili da configurare all'interno della tua classe - come una e-mail invio di riferimenti di servizio - e così via. Ma non lasciarti abbattere! Vedrai che la progettazione generale del codice migliorerà man mano che inizierai a scrivere test unitari e più testerai, più sarai sicuro di poter apportare ulteriori modifiche senza temere di violare l'applicazione o introdurre bug .

Ci sono diversi motivi per testare il tuo codice unitario, ma con il passare del tempo, scoprirai che il tempo che risparmi nei test è uno dei migliori motivi per farlo. In un sistema che ho appena consegnato, ho insistito per eseguire test automatici dell'unità nonostante le affermazioni che avrei impiegato più tempo a fare i test che a testare il sistema manualmente. Con tutti i miei test unitari, ho eseguito più di 400 test case in meno di 10 minuti, e ogni volta che dovevo fare una piccola modifica nel codice, tutto mi serviva per essere sicuro che il codice funzionasse ancora senza errori. minuti. Riesci a immaginare il tempo che si impiegherebbe per eseguire a mano questi 400 casi di test?

Quando si tratta di test automatici, che si tratti di test unitari o test di accettazione, tutti pensano che sia uno sforzo inutile codificare ciò che si può fare manualmente, ea volte è vero, se si prevede di eseguire i test una sola volta. La parte migliore dei test automatici è che puoi eseguirli più volte senza sforzo, e dopo la seconda o la terza esecuzione, il tempo e lo sforzo che hai sprecato sono già stati pagati.

Un ultimo consiglio sarebbe non solo testare il tuo codice, ma iniziare a fare test prima (vedi TDD e BDD per altro)

10
Alexandre Brasil

I test unitari sono anche particolarmente utili quando si tratta di refactoring o riscrittura di un pezzo di un codice. Se hai una buona copertura di test unitari, puoi refactoring con fiducia. Senza test unitari, è spesso difficile garantire che tu non abbia infranto nulla.

8
killdash10

Lavoro come ingegnere di manutenzione di una base di codice scarsamente documentata, terribile e grande. Vorrei che le persone che hanno scritto il codice avessero scritto i test unitari per questo.
Ogni volta che apporto una modifica e aggiorno il codice di produzione ho paura che possa introdurre un bug per non aver preso in considerazione alcune condizioni.
Se avessero scritto il test, apportare modifiche alla base del codice sarebbe stato più semplice e veloce (allo stesso tempo la base del codice sarebbe in uno stato migliore) ..

Penso che i test unitari si dimostrino molto utili quando si scrivono api o framework che devono durare per molti anni e che devono essere utilizzati/modificati/evoluti da persone diverse dai codificatori originali.

7
mic.sca

In breve - sì. Valgono ogni grammo di sforzi ... fino a un certo punto. I test sono, alla fine della giornata, ancora in codice, e in modo molto simile alla crescita tipica del codice, i test dovranno eventualmente essere sottoposti a refactoring per essere mantenibili e sostenibili. C'è una tonnellata di GOTCHAS! quando si tratta di test di unità, ma uomo oh uomo oh uomo, niente, e intendo NULLA consente a uno sviluppatore di apportare modifiche in modo più sicuro di un ricco insieme di test unitari.

Sto lavorando a un progetto in questo momento .... è in qualche modo TDD, e abbiamo la maggior parte delle nostre regole aziendali come prove collaudate ... abbiamo circa 500 test unitari in questo momento. Questa iterazione passata dovevo rinnovare la nostra origine dati e il modo in cui la nostra applicazione desktop si interfacciava con quell'origine dati. Mi ci sono voluti un paio di giorni, per tutto il tempo che ho continuato a eseguire i test unitari per vedere cosa ho rotto e riparato. Fare un cambiamento; Costruisci ed esegui i tuoi test; correggi ciò che hai rotto Lavare, sciacquare, ripetere se necessario. Ciò che avrebbe tradizionalmente richiesto giorni di QA e carichi di stress in barca era invece un'esperienza breve e piacevole.

Preparati in anticipo, un po 'di sforzo in più, e paga 10 volte più tardi quando devi iniziare a giocare con funzionalità e funzionalità di base.

Ho comprato questo libro - è una Bibbia di xUnit Testing knowledge - è probabilmente uno dei libri più citati sul mio scaffale e lo consulta quotidianamente: link text

7
cranley

Occasionalmente o io o uno dei miei colleghi passeremo un paio d'ore a cogliere il fondo di un bug un po 'oscuro e una volta che la causa del bug viene rilevata il 90% del tempo in cui il codice non viene testato. Il test unitario non esiste perché lo sviluppatore sta tagliando gli angoli per risparmiare tempo, ma poi perde questo e più il debug.

Prendendo la piccola quantità di tempo per scrivere un test unitario può risparmiare ore di debugging futuro.

7
Jon Cahill

Quando hai detto, "il nostro codice base non si presta a test facili" è il primo segno di un odore di codice. Scrivere i test delle unità significa che in genere si scrive codice in modo diverso per rendere il codice più verificabile. Questa è una buona cosa secondo me per quello che ho visto nel corso degli anni nello scrivere il codice per cui ho dovuto scrivere dei test, mi ha costretto a proporre un design migliore.

6
Keith Elder

Non lo so. Un sacco di posti non fanno test unitari, ma la qualità del codice è buona. Microsoft esegue un test unitario, ma Bill Gates ha dato una schermata blu alla sua presentazione.

6
BigTiger

Il test unitario vale sicuramente la pena. Purtroppo hai scelto uno scenario difficile (ma purtroppo comune) in cui implementarlo.

Il miglior vantaggio dai test unitari che otterrai è quando lo utilizzi da zero - su alcuni piccoli progetti selezionati ho avuto la fortuna di scrivere i miei test unitari prima di implementare le mie lezioni (l'interfaccia era già completa in questo punto). Con i test di unità appropriati, troverai e sistemerai i bug nelle tue classi mentre sono ancora nella loro infanzia e non ovunque vicino al sistema complesso che in futuro verranno integrati senza dubbio.

Se il tuo software è fortemente orientato agli oggetti, dovresti essere in grado di aggiungere test di unità a livello di classe senza troppi sforzi. Se non sei così fortunato, dovresti comunque provare a incorporare i test unitari ovunque tu sia. Assicurati che quando aggiungi nuove funzionalità i nuovi pezzi siano ben definiti con interfacce chiare e troverai test unitari che ti semplificheranno la vita.

6
Matt

Ho scritto un post sul blog molto grande sull'argomento. Ho scoperto che il test unitario da solo non vale il lavoro e di solito viene tagliato quando le scadenze si avvicinano.

Invece di parlare dei test unitari dal punto di vista della verifica "test-after", dovremmo esaminare il vero valore trovato quando si decide di scrivere una specifica/test/idea prima dell'implementazione.

Questa semplice idea ha cambiato il modo in cui scrivo software e non tornerò alla "vecchia" maniera.

In che modo il primo sviluppo del test mi ha cambiato la vita

5
Toran Billups

Una cosa che nessuno ha ancora menzionato sta ottenendo l'impegno di tutti gli sviluppatori di eseguire e aggiornare effettivamente qualsiasi test automatizzato esistente. I test automatici di cui si è riusciti a trovare e che si sono rotti a causa del nuovo sviluppo perdono molto valore e rendono i test automatizzati davvero dolorosi. La maggior parte di questi test non indicherà bug poiché lo sviluppatore ha testato il codice manualmente, quindi il tempo speso per aggiornarli è solo uno spreco.

Convincere gli scettici a non distruggere il lavoro che gli altri stanno facendo sui test unitari è molto più importante per ottenere valore dai test e potrebbe essere più facile.

Le ore di aggiornamento dei test interrotti a causa di nuove funzionalità ogni volta che si effettua l'aggiornamento dal repository non sono né produttive né divertenti.

3
Samuel Åslund

Ho scoperto TDD un paio di anni fa e da allora ho scritto tutti i miei progetti per animali domestici che lo utilizzano. Ho stimato che ci vuole all'incirca nello stesso tempo per TDD un progetto, dato che serve per metterlo insieme, ma ho una tale maggiore fiducia nel prodotto finale che non posso aiutare un sentimento di realizzazione.

Sento anche che migliora il mio stile di progettazione (molto più orientato all'interfaccia nel caso in cui abbia bisogno di prendere in giro le cose insieme) e, come scrive il post verde in alto, aiuta con "codifica costipazione": quando non sai cosa per scrivere dopo, o hai un compito scoraggiante di fronte a te, puoi scrivere piccolo.

Infine, trovo che l'applicazione di TDD di gran lunga più utile sia nel debug, se non altro perché hai già sviluppato un framework interrogativo con il quale puoi spingere il progetto a produrre il bug in modo ripetibile.

3
Kaz Dragon

Sì, il test unitario vale sicuramente la pena, ma dovresti sapere che non è un proiettile d'argento. Il test unitario è lavoro e dovrai lavorare per mantenere il test aggiornato e pertinente al cambio del codice, ma il valore offerto vale lo sforzo che devi compiere. La capacità di refactoring con l'impunità è un enorme vantaggio in quanto puoi sempre convalidare la funzionalità eseguendo i test dopo ogni codice di modifica. Il trucco è quello di non rimanere troppo attaccati all'unità di lavoro che stai testando o ai requisiti dei test di impalcatura e quando un test unitario è davvero un test funzionale, ecc. Le persone discutono di queste cose per ore alla fine e la realtà è che qualsiasi test che fai come codice di scrittura è meglio che non farlo. L'altro assioma riguarda la qualità e non la quantità: ho visto basi di codice con migliaia di test che sono essenzialmente prive di significato, dal momento che il resto in realtà non verifica nulla di utile o qualsiasi dominio specifico come le regole aziendali, ecc. Del dominio particolare. Ho anche visto codebase con una copertura del 30% del codice, ma i test sono stati rilevanti, significativi e davvero impressionanti, poiché hanno testato la funzionalità principale del codice per il quale è stato scritto ed hanno espresso il modo in cui il codice dovrebbe essere utilizzato.

Uno dei miei trucchi preferiti quando esploro nuovi framework o codebase è scrivere test unitari per "it" per scoprire come funzionano le cose. È un ottimo modo per saperne di più su qualcosa di nuovo invece di leggere un doc asciutto :)

3
Vinny Carpenter

Recentemente ho vissuto esattamente la stessa esperienza sul mio posto di lavoro e ho scoperto che molti di loro conoscevano i benefici teorici, ma dovevano essere venduti in modo specifico sui vantaggi, quindi ecco i punti che ho usato (con successo):

  • Risparmiano tempo quando eseguono test negativi, in cui gestisci input inattesi (puntatori nulli, valori fuori limite, ecc.), In quanto puoi fare tutto ciò in un unico processo.
  • Forniscono un feedback immediato al momento della compilazione per quanto riguarda lo standard delle modifiche.
  • Sono utili per testare rappresentazioni di dati interne che potrebbero non essere esposte durante il normale runtime.

e il grande ...

  • Potresti non aver bisogno di test delle unità, ma quando qualcuno entra e modifica il codice senza una piena comprensione, può cogliere molti degli stupidi errori che potrebbero commettere.
3
dlanod

Dalla mia esperienza, unit test e test di integrazione sono un "MUST HAVE" in ambienti software complessi.

Per convincere gli sviluppatori del tuo team a scrivere test di unità, potresti prendere in considerazione l'integrazione di analisi di regressione del test di unità nel tuo ambiente di sviluppo (ad esempio, nel tuo processo di compilazione giornaliero).

Una volta che gli sviluppatori sanno che se un test unitario fallisce, non devono dedicare così tanto tempo al debug per trovare il problema, ma sarebbero più incoraggiati a scriverli.

Ecco uno strumento che fornisce tale funzionalità:

strumento di analisi della regressione dei test di unità

2
Liorp

Se stai usando NUnit, una demo semplice ma efficace è quella di eseguire la suite di test NUnit di fronte a loro. Vedere una vera suite di test dare un codice base a un allenamento vale più di mille parole ...

2
Garth Gilmour

L'unica cosa da tenere a mente sui test unitari è che è un conforto per lo sviluppatore.

Al contrario, i test funzionali sono per gli utenti: ogni volta che aggiungi un test funzionale, stai testando qualcosa che l'utente vedrà. Quando aggiungi un test unitario, stai semplificando la vita come sviluppatore. È un po 'di lusso in questo senso.

Tieni a mente questa dicotomia quando devi fare una scelta tra la scrittura di un'unità o un test funzionale.

2
Cedric Beust

Sono d'accordo con il punto di vista opposto alla maggioranza qui: Va bene non scrivere i test delle unità Soprattutto la programmazione prototipo-pesante (AI per esempio) è difficile da combinare con i test unitari.

2
DSblizzard

Il test unitario aiuta molto nei progetti che sono più grandi di quanto uno sviluppatore possa tenere in testa. Ti consentono di eseguire la suite di test unitari prima di effettuare il check-in e scoprire se hai rotto qualcosa. Ciò riduce un lotto in caso di istanze di dover sedersi e intrecciare i pollici mentre si aspetta che qualcun altro risolva un bug da loro controllato, o che si rechi al problemi di ripristinare il loro cambiamento in modo da poter fare un po 'di lavoro. È anche estremamente prezioso nel refactoring, quindi puoi essere sicuro che il codice refactored supera tutti i test effettuati dal codice originale.

2
Max Rible Kaehn

Con la suite di test unità è possibile apportare modifiche al codice lasciando intatto il resto delle funzionalità. È un grande vantaggio. Quando usi la codifica di una nuova funzionalità, usi la suite di test di unità e di regressione.

2
Shinwari

L'intero punto di test unitario è rendere i test facili. È automatizzato "fai il test" e il gioco è fatto. Se uno dei problemi che affronti è difficile da testare il codice, questa è la ragione migliore per utilizzare il test dell'unità.

1
Deathbob

Proprio oggi, ho dovuto cambiare una classe per la quale è stato scritto in precedenza un test unitario.
Il test stesso era ben scritto e includeva scenari di test a cui non avevo nemmeno pensato.
Fortunatamente tutti i test sono stati superati e il mio cambiamento è stato rapidamente verificato e inserito nell'ambiente di test con sicurezza.

1
crowne

Quando esegui il test manuale del software, normalmente hai un piccolo insieme di test/azioni che usi. Alla fine, i dati o le azioni di input verranno trasformati automaticamente in modo da navigare su problemi noti. I test unitari dovrebbero essere lì per ricordarti che le cose non funzionano correttamente.

Raccomando di scrivere test prima del codice, aggiungendo nuovi test/dati per far evolvere la funzionalità del codice principale!

1
Ray Hayes

Come studente di fisica sono molto motivato a dimostrare che il mio codice funziona come dovrebbe. Potresti provarlo logicamente, il che aumenta drasticamente di difficoltà man mano che l'implementazione diventa più complessa, oppure puoi provare (il più vicino possibile) una prova empirica della funzione attraverso una buona sperimentazione.

Se non si fornisce la prova logica della funzione, è necessario testare. L'unica alternativa è dire "Penso che il codice funzioni ..."

1
Fredrik

@George Stocker "Sfortunatamente la nostra base di codice non si presta a facili test". Tutti sono d'accordo sul fatto che ci siano dei benefici per i test unitari, ma sembra che per questo codice i costi siano alti. Se i costi sono maggiori dei benefici, perché dovrebbero essere entusiasti? Ascolta i tuoi colleghi; forse per loro il dolore percepito dei test unitari è maggiore del valore percepito dei test unitari.

In particolare, cerca di ottenere valore il prima possibile, e non un po 'di valore "xUnit è verde", ma un codice pulito che gli utenti e i manutentori apprezzano. Forse devi mandare i test unitari per una singola iterazione e poi discutere se vale la pena o meno.

1
Trystan Spangler

Fai le prime cose che controlli non correlate al test dell'unità. Lavoro principalmente in Perl, quindi questi sono esempi specifici per Perl, ma puoi adattarti.

  • Ogni modulo carica e compila correttamente? In Perl, si tratta di creare un Foo.t per ogni Foo.pm nel code base che esegue:

    use_ok( 'Foo' );
    
  • Tutto il POD (Plain Ol 'Documentation) è formattato correttamente? Utilizzare Test :: Pod per convalidare la validità della formattazione di tutto il POD in tutti i file.

Potresti non pensare che queste siano grandi cose, e non lo sono, ma posso garantire che prenderesti un po 'di puttane. Quando questi test vengono eseguiti una volta all'ora, e intercetta il commit prematuro di qualcuno, avrai gente che dice "Ehi, è molto bello".

1
Andy Lester

Uno dei vantaggi del test unitario è la prevedibilità.

Prima dei test unitari avrei potuto prevedere con un alto grado di precisione quanto tempo ci sarebbe voluto per codificare qualcosa, ma non quanto tempo avrei avuto bisogno di eseguire il debug.

In questi giorni, dal momento che posso pianificare le prove che sto per scrivere, so per quanto tempo ci vorrà la codifica e, alla fine della codifica, il sistema è già stato sottoposto a debugging! Questo porta alla prevedibilità del processo di sviluppo, che rimuove molta della pressione ma conserva ancora tutta la gioia !!.

1
Raz

Unit Testing è una delle metodologie più utilizzate per il codice di alta qualità. Il suo contributo a un codice più stabile, indipendente e documentato è ben dimostrato. Il codice di test unitario viene considerato e gestito come parte integrante del repository e, come tale, richiede sviluppo e manutenzione. Tuttavia, gli sviluppatori spesso incontrano una situazione in cui le risorse investite in test unitari non sono fruttuose come ci si aspetterebbe. In un mondo ideale ogni metodo che codificheremo avrà una serie di test che coprono il suo codice e convalidano la sua correttezza. Tuttavia, solitamente a causa di limiti di tempo, saltiamo alcuni test o scriviamo quelli di scarsa qualità. In tale realtà, pur tenendo presente la quantità di risorse investite nello sviluppo e nella manutenzione dei test unitari, ci si deve chiedere, visto il tempo a disposizione, quale codice merita maggiormente i test? E dai test esistenti, quali test vale la pena di mantenere e mantenere? Vedi qui

0
RoiG

I test unitari aiutano a rilasciare software con meno errori riducendo al contempo i costi di sviluppo complessivi. Puoi fare clic sul link per saperne di più sui vantaggi del test delle unità

0
Steve_0

Chi stai cercando di convincere? Ingegneri o manager? Se stai cercando di convincere i tuoi colleghi di ingegnere, penso che la cosa migliore da fare sia fare appello al loro desiderio di creare un software di alta qualità. Ci sono numerosi studi che mostrano che trova bug, e se si preoccupano di fare un buon lavoro, questo dovrebbe essere sufficiente per loro.

Se stai cercando di convincere la direzione, molto probabilmente dovrai fare una sorta di ragionamento costi/benefici dicendo che il costo dei difetti che non saranno rilevati è maggiore del costo di scrittura dei test. Assicurati di includere anche costi intagibili, come la perdita della fiducia dei clienti, ecc.

0
Craig H

Questo è molto. Net-centric, ma qualcuno ha provato Pex ?

Ero estremamente scettico fino a quando ho provato - e wow, che spettacolo. Prima ho pensato "Non mi convincerò di questo concetto fino a quando non capirò che cosa è in realtà fare per beneficiarmi". Mi è bastato un solo tentativo per farmi cambiare idea e dire "Non ho cura come sai che c'è il rischio di un'eccezione fatale lì, ma lì è e ora so che devo affrontarlo "

Forse l'unico lato negativo di questo comportamento è che segnalerà tutto e ti darà un backlog di sei mesi. Ma se avessi il debito del codice, hai sempre avuto un debito in codice, non lo sapevi. Dicendo a PM ci sono potenziali duecentomila punti di errore quando prima di essere a conoscenza di alcune dozzine è una brutta prospettiva, il che significa che è fondamentale che il concetto sia spiegato per primo.

0
Tom W