Unit Testing vale lo sforzo? [chiuso]

Sto lavorando per integrare i test unitari nel processo di sviluppo del team su cui lavoro e ci sono alcuni scettici. Quali sono alcuni buoni modi per convincere gli sviluppatori scettici nel team del valore di Unit Testing? Nel mio caso specifico, aggiungeremmo Test unità mentre aggiungiamo funzionalità o bug corretti. Purtroppo la nostra base di codice non si presta a test facili.

Ogni giorno nel nostro ufficio c'è uno scambio che va qualcosa del genere:

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

I dettagli cambiano ogni giorno, ma il sentimento no. I test unitari e lo sviluppo test-driven (TDD) hanno così tanti vantaggi nascosti e personali, oltre a quelli ovvi che non puoi davvero spiegare a qualcuno fino a quando non lo fanno da soli.

Ma, ignorandolo, ecco il mio tentativo!

1. Test unitari ti consente di apportare grandi modifiche al codice rapidamente. Sai che funziona ora perché hai eseguito i test, quando apporti le modifiche che devi apportare, devi far funzionare nuovamente i test. Questo fa risparmiare ore.

2. TDD ti aiuta a capire quando interrompere la codifica. I tuoi test ti danno la certezza di aver fatto abbastanza per ora e possono smettere di modificare e passare alla prossima cosa.

3. I test e il codice lavorano insieme per ottenere un codice migliore. Il tuo codice potrebbe essere errato / difettoso. Il TEST potrebbe essere difettoso / difettoso. In TDD stai scommettendo sulle probabilità che entrambi siano cattivi / buggy bassi. Spesso è il test che deve essere risolto ma è comunque un buon risultato.

4. TDD aiuta con costipazione di codifica. Di fronte a un grande e scoraggiante lavoro prima di scrivere, i test ti faranno muovere rapidamente.

5. I test unitari ti aiutano a comprendere veramente il design del codice su cui stai lavorando. Invece di scrivere codice per fare qualcosa, stai iniziando delineando tutte le condizioni a cui stai sottoponendo il codice e quali output ti aspetteresti da quello.

6. I test unitari ti danno un feedback 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 avevi interrotto dopo un'interruzione perché puoi vedere dove sei arrivato: quella prossima luce rossa che deve essere riparata.

7. Contrariamente al popolare test delle unità di credenza non significa scrivere il doppio del codice o codificare più lentamente. È più veloce e più robusto della codifica senza test una volta che hai capito. Il codice di prova stesso è di solito relativamente banale e non aggiunge un grande sovraccarico a ciò che stai facendo. Questo è quello in cui crederai solo quando lo fai :)

8. Penso che sia stato Fowler a dire: "I test imperfetti, eseguiti frequentemente, sono molto meglio dei test perfetti che non sono mai stati scritti". Interpreto questo come dandomi il permesso di scrivere test dove penso che saranno più utili anche se il resto della mia copertura del codice è terribilmente incompleto.

9. Buoni test unitari possono aiutare a documentare e definire cosa dovrebbe fare qualcosa

10. I test unitari aiutano a riutilizzare il codice. Migrare sia il codice che i test nel nuovo progetto. Modifica il codice fino a quando i test non vengono eseguiti nuovamente.

Molto lavoro a cui sono coinvolto non funziona bene Unit Test (interazioni con l'utente di applicazioni web ecc.), Ma anche così siamo tutti testati infetti in questo negozio e più felici quando abbiamo i nostri test vincolati. Non posso raccomandare vivamente l'approccio.

Il test unitario è molto simile all'andare in palestra. Sai che è buono per te, tutti gli argomenti hanno senso, quindi inizi a lavorare. C'è una corsa iniziale, che è grandiosa, ma dopo qualche giorno inizi a chiederti se valga la pena. Ti stai prendendo un'ora della tua giornata per cambiarti e correre su una ruota per criceti e non sei sicuro di guadagnare davvero altro che gambe e braccia doloranti.

Quindi, dopo forse una o due settimane, proprio mentre il dolore sta scomparendo, inizia una grande scadenza. Devi passare ogni ora del risveglio a cercare di fare un lavoro "utile", in modo da ritagliare cose estranee, come andare in palestra. Ti allontani dall'abitudine e quando Big Deadline è finito, sei tornato al punto di partenza. Se riesci a tornare in palestra, ti senti male quanto lo eri la prima volta che sei andato.

Fai qualche lettura per vedere se stai sbagliando qualcosa. Inizi a provare un po 'di disprezzo irrazionale verso tutte le persone in forma e felici che esaltano le virtù dell'esercizio. Ti rendi conto che non hai molto in comune. Non devono guidare 15 minuti fuori mano per andare in palestra; ce n'è uno nel loro edificio. Non devono discutere con nessuno sui benefici dell'esercizio; è solo qualcosa che tutti fanno e accettano come importante. Quando una Big Deadline si avvicina, non gli viene detto che l'esercizio fisico 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 unitario può richiedere un enorme sforzo se si ha a che fare con una base di codice spaghetti in un'azienda che in realtà non apprezza la qualità del codice. (Molti manager canteranno le lodi di Unit Testing, ma ciò non significa che si attaccheranno quando è importante.)

Se stai cercando di introdurre Unit Testing nel tuo lavoro e non stai vedendo tutto il sole e gli arcobaleni che ti sei aspettato, non incolpare te stesso. Potrebbe essere necessario trovare un nuovo lavoro per far funzionare davvero i test unitari.

Il modo migliore per convincere ... trova un bug, scrivi un test unitario, correggi il bug.

È improbabile che quel particolare bug appaia mai più, e puoi provarlo con il tuo test.

Se lo fai abbastanza, gli altri prenderanno rapidamente piede.

thetalkingwalnut chiede:

Quali sono alcuni buoni modi per convincere gli sviluppatori scettici nel team del valore di Unit Testing?

Tutti qui accumuleranno all'improvviso molte ragioni per cui i test unitari sono buoni. Tuttavia, trovo che spesso il modo migliore per convincere qualcuno di qualcosa sia ascoltare la sua argomentazione e affrontarla punto per punto. Se li ascolti e li aiuti a verbalizzare le loro preoccupazioni, puoi indirizzarli tutti e forse convertirli nel tuo punto di vista (o almeno, lasciarli senza una gamba su cui stare in piedi). Chissà? Forse ti convinceranno perché i test unitari non sono adatti alla tua situazione. Non probabile, ma possibile. Forse se pubblichi i loro argomenti contro unit test, possiamo aiutare a identificare i controargomenti.

È importante ascoltare e comprendere entrambe le parti dell'argomento. Se provi ad adottare i test unitari troppo zelantemente senza riguardo alle preoccupazioni della gente, finirai con una guerra religiosa (e probabilmente test unitari davvero senza valore). Se lo adotti lentamente e inizi applicandolo dove vedrai il massimo beneficio al minor costo, potresti essere in grado di dimostrare il valore dei test unitari e avere maggiori 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 elaborare un argomento convincente.

I test unitari sono uno strumento, come qualsiasi altro, e dovrebbero essere applicati in modo tale che i benefici (la cattura di bug) siano superiori ai costi (lo sforzo di scriverli). Non usarli se / dove non hanno senso e ricorda che fanno solo parte del tuo arsenale di strumenti (ad es. Ispezioni, asserzioni, 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 es. Troppo semplice per valerne la pena o troppo difficile per valerne la pena) e su come verrà altrimenti verificato il metodo (ad es. Ispezione, asserzioni , metodi formali, test interattivi / di integrazione). Devono considerare che alcune verifiche come ispezioni e prove formali vengono eseguite in un determinato momento e quindi devono essere ripetute ogni volta che cambia il codice di produzione, mentre i test unitari e le asserzioni possono essere usati come test di regressione (scritti una volta ed eseguiti ripetutamente in seguito ). A volte sono d'accordo con loro, ma più spesso discuterò se un metodo sia 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 unitario a 5 righe? Queste 5 righe di codice verranno eseguite ogni notte (esegui build notturne, giusto?) Per il prossimo anno o più e ne varrà la pena se anche solo una volta capita di riscontrare un problema che potrebbe richiedere 15 minuti o più per identificare e debug. Inoltre, scrivere i semplici test unitari aumenta il conteggio dei test unitari, il che rende lo sviluppatore attraente.

   • D'altra parte, se uno sviluppatore sostiene che un metodo sembra troppo difficile da testare l'unità (non vale la pena di uno sforzo significativo richiesto), forse è una buona indicazione che il metodo deve essere suddiviso o refactored per testare le parti facili. Di solito, si tratta di 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 rifattorizzati in un metodo che ottiene la risorsa (ad es. Chiama getTime ()) e un metodo che accetta la risorsa come argomento (ad es. Prende il timestamp come parametro). Li ho lasciati saltare il test del metodo che recupera la risorsa e invece scrivono un test unitario per il metodo che ora accetta la risorsa come argomento. Di solito, questo rende molto più semplice scrivere il test unitario e quindi vale la pena scriverlo.

2. Lo sviluppatore deve tracciare una "linea nella sabbia" su quanto dovrebbero essere completi i test unitari. Più avanti nello sviluppo, ogni volta che troviamo un bug, dovrebbero determinare se test unitari più completi avrebbero colto il problema. In tal caso e se tali bug emergono ripetutamente, devono spostare la "linea" verso la scrittura di unit test più completi in futuro (a partire dall'aggiunta o dall'espansione del test unitario per il bug corrente). Devono trovare il giusto equilibrio.

La sua importante per realizzare i test di unità non sono una pallottola d'argento e non v'è una cosa una come troppo unit testing. Nel mio posto di lavoro, ogni volta che impariamo le lezioni, sento inevitabilmente "dobbiamo scrivere più unit test". La direzione annuisce concorde perché è stata sbattuta nella testa che "unit test" == "buono".

Tuttavia, dobbiamo comprendere l'impatto di "più unit test". Uno sviluppatore può scrivere solo ~ N righe di codice a settimana e devi capire quale percentuale di quel codice dovrebbe essere il codice unit test rispetto al codice di produzione. Un ambiente di lavoro lassista potrebbe avere il 10% del codice come test unitari e il 90% del codice come codice di produzione, risultando in un prodotto con molte funzionalità (sebbene molto buggy) (pensate a MS Word). D'altra parte, un negozio rigoroso con il 90% di unit test e il 10% di codice di produzione avrà un prodotto solido con pochissime funzionalità (pensate "vi"). Potresti non sentire mai rapporti sull'arresto anomalo di quest'ultimo prodotto, ma ciò ha probabilmente a che fare 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 rigoroso (90% unit test / 10% codice di produzione) crei un prodotto con esattamente 2 funzioni (presupponendo che il 5% del codice di produzione == 1 funzione). Se il cliente arriva e cambia 1 delle funzionalità, tale modifica elimina il 50% del codice (45% dei test unitari e 5% del codice di produzione). Il negozio lassista (10% unit test / 90% codice di produzione) ha un prodotto con 18 caratteristiche, nessuna delle quali funziona molto bene. I loro clienti rinnovano completamente i requisiti per 4 delle loro funzionalità. Anche se la modifica è 4 volte più grande, solo la metà della base di codice viene eliminata (~ 25% = ~ 4,4% unit test + 20% del codice di produzione).

Il mio punto è che devi comunicare che hai compreso quell'equilibrio tra test di unità troppo piccoli e troppi, essenzialmente che hai riflettuto su entrambi i lati del problema. Se riesci a convincere i tuoi colleghi e / o la tua gestione di ciò, ottieni credibilità e forse hai maggiori possibilità di conquistarli.

Ho giocato diverse volte con i test unitari e sono ancora convinto che valga la pena, vista la mia situazione.

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

Quando ho scritto test unitari sulla logica di business, non mi ha mai davvero aiutato a lungo termine. Poiché lavoro principalmente su progetti da solo, tendo a sapere intuitivamente su quali aree del codice possono essere influenzate da qualcosa su cui sto lavorando, e collaudo queste aree manualmente. Voglio fornire una soluzione al mio cliente il più rapidamente possibile e i test delle unità spesso sembrano una perdita di tempo. Elenco i test manuali e li percorro da solo, spuntandoli mentre vado.

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

Una cosa grandiosa dei test unitari è che servono come documentazione per come il tuo codice dovrebbe comportarsi. I buoni test sono un po 'come un'implementazione di riferimento e i compagni di squadra possono guardarli per vedere come integrare il loro codice con il tuo.

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

• il test di regressione elimina la paura di apportare modifiche al codice (non c'è niente come il caldo bagliore di vedere il codice funzionare o esplodere ogni volta che viene apportata una modifica)
• esempi di codice eseguibile per altri membri del team (e te stesso tra sei mesi ..)
• refactoring spietato - 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 unit-test associato in pochi secondi.

Dovresti testare il meno possibile!

vale a dire, dovresti scrivere abbastanza unit test per rivelare l'intento. Questo spesso viene sorpreso. Il test unitario ti costa. Se apporti modifiche e devi modificare i test, sarai meno agile. Mantenere 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, finiscono per rallentarti.

Non ho visto questo in nessuna delle altre risposte, ma una cosa che ho notato è che avrei potuto eseguire il debug molto più velocemente . Non è necessario eseguire il drill down della tua app con la giusta sequenza di passaggi per ottenere il codice da correggere, solo per scoprire di aver fatto un errore booleano e di dover ripetere tutto. Con un unit test, puoi semplicemente entrare direttamente nel codice di cui stai eseguendo il debug.

[Ho un punto da dire che non posso vedere sopra]

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

Pensaci, scrivi una funzione per forse analizzare una stringa e rimuovere i nuovi caratteri di linea. Come sviluppatore principiante o esegui alcuni casi attraverso di esso dalla riga di comando implementandolo in Main () oppure colpisci un front-end visivo con un pulsante, collega la tua funzione a un paio di caselle di testo e un pulsante e vedi che succede.

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

Scrivi qualcosa di più complesso. Genera errori quando si passano alcuni casi (unit test) e si esegue il debug nel codice e si traccia comunque. Guardi i valori mentre vai avanti e decidi se sono giusti o sbagliati. Questo è un test unitario in una certa misura.

Il test di unità qui sta davvero prendendo quel comportamento, formalizzandolo in un modello strutturato e salvandolo in modo da poter rieseguire facilmente quei test. Se si scrive un caso di test unitario "corretto" anziché il test manuale, ci vuole la stessa quantità di tempo, o forse meno di quanto si è sperimentati, e si ha a disposizione per ripetere ancora e ancora

Per anni, ho cercato di convincere le persone che dovevano 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 unit test per il codice. Quasi nessuno era in disaccordo con me. Non puoi essere in disaccordo con qualcosa di ovvio e qualsiasi persona intelligente vedrà i vantaggi del test unitario e del TDD.

Il problema con i test unitari è che richiede un cambiamento comportamentale ed è molto difficile cambiare il comportamento delle persone. Con le parole, avrai molte persone 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 tutte le discussioni che potresti avere. Se vedono che non stai solo parlando di unit test o TDD, ma stai facendo ciò che predichi e hai successo, le persone cercheranno di imitarti.

Dovresti anche assumere un ruolo di primo piano perché nessuno scrive i test unitari 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, i modi di dire 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 unit test o TDD nella loro cassetta degli attrezzi.

I cambiamenti non accadranno durante la notte, ma con un po 'di pazienza, potresti raggiungere il tuo obiettivo.

Una parte importante dello sviluppo guidato dai test che è spesso sorpreso è la scrittura di codice testabile. All'inizio sembra una specie di compromesso, ma scoprirai che anche il codice testabile è in definitiva modulare, gestibile e leggibile. Se hai ancora bisogno di aiuto per convincere le persone, questa è una bella e semplice presentazione dei vantaggi del test unitario.

Se la tua base di codice esistente non si presta al test unitario ed è già in produzione, potresti creare più problemi di quanti ne risolvi provando a riformattare tutto il tuo codice in modo che sia testabile dall'unità.

Potresti invece fare meglio a impegnarti per migliorare i tuoi test di integrazione. C'è un sacco di codice là fuori che è solo più semplice da scrivere senza un unit test e se un QA può convalidare la funzionalità rispetto a un documento di requisiti, allora il gioco è fatto. Spedirlo.

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 procedura memorizzata. Cosa test unitario? Se la pagina fa quello che dovrebbe fare, dovresti davvero ridisegnarla in più livelli in modo da avere qualcosa da automatizzare?

Una delle cose migliori del test unitario è 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 dall'unità, non è raro avere un alto livello di accoppiamento tra classi, oggetti difficili da configurare all'interno della classe, come un'e-mail invio di riferimento al servizio - e così via. Ma non lasciarti abbattere da questo! Vedrai che la tua progettazione complessiva del codice migliorerà quando inizierai a scrivere unit-test, e più testerai, più sarai sicuro di fare ancora più modifiche ad esso senza paura di rompere l'applicazione o introdurre bug .

Esistono diversi motivi per testare l'unità del codice, ma col passare del tempo scoprirai che il tempo che risparmi sui test è uno dei motivi migliori per farlo. In un sistema che ho appena consegnato, ho insistito nel fare test di unità automatizzati nonostante le affermazioni secondo cui avrei passato molto più tempo a fare i test di quanti ne avrei testati manualmente. Dopo aver completato tutti i test delle unità, eseguo più di 400 casi di test in meno di 10 minuti e ogni volta che ho dovuto apportare una piccola modifica al codice, mi sono reso conto che il codice funzionava senza errori minuti. Riesci a immaginare il tempo che ci vorrebbe per eseguire manualmente oltre 400 casi di test?

Quando si tratta di test automatici, che si tratti di test unitari o test di collaudo, tutti pensano che sia uno sforzo sprecato per codificare ciò che è possibile fare manualmente, e talvolta è 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à pagati.

Un ultimo consiglio sarebbe non solo testare l'unità del codice, ma iniziare prima a fare test (vedi TDD e BDD per ulteriori informazioni)

I test unitari sono particolarmente utili quando si tratta di refactoring o riscrittura di un pezzo un codice. Se disponi di una buona copertura per i test unitari, puoi effettuare il refactoring in tutta sicurezza. Senza test unitari, è spesso difficile assicurarsi di non aver rotto nulla.

In breve, sì. Valgono ogni oncia di sforzo ... fino a un certo punto. I test sono, in fin dei conti, ancora codice, e proprio come la tipica crescita del codice, i test dovranno eventualmente essere sottoposti a refactoring per essere sostenibili e sostenibili. C'è una tonnellata di GOTCHAS! quando si tratta di unit test, ma man oh man oh man, niente, e intendo NULLA autorizza uno sviluppatore a apportare modifiche con maggiore sicurezza rispetto a un ricco set di unit test.

Sto lavorando a un progetto in questo momento ... è un po 'TDD, e abbiamo la maggior parte delle nostre regole di business incapsulate come test ... abbiamo circa 500 unità di test in questo momento. In passato ho dovuto rinnovare la nostra fonte di dati e come la nostra applicazione desktop si interfaccia con quella fonte di dati. Mi ci sono voluti un paio di giorni, per tutto il tempo ho continuato a eseguire test unitari per vedere cosa ho rotto e risolto. Fare un cambiamento; Costruisci ed esegui i tuoi test; risolvi ciò che hai rotto. Lavare, risciacquare, ripetere se necessario. Ciò che tradizionalmente avrebbe richiesto giorni di controllo qualità 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 cercare con le caratteristiche / funzionalità di base.

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

Di tanto in tanto io o uno dei miei colleghi passeremo un paio d'ore a giungere alla fine di un bug leggermente oscuro e una volta trovata la causa del bug il 90% delle volte che il codice non è testato in unità. Il test unitario non esiste perché lo sviluppatore sta tagliando gli angoli per risparmiare tempo, ma poi perde questo e più debug.

Richiedere il piccolo tempo necessario per scrivere un test unitario può risparmiare ore di debug futuri.

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

Penso che i test unitari risultino molto utili quando si scrivono API o framework che devono durare per molti anni e che devono essere usati / modificati / evoluti da persone diverse dai programmatori originali.

Il test unitario merita sicuramente lo sforzo. Purtroppo hai scelto uno scenario difficile (ma purtroppo comune) in cui implementarlo.

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

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

Quando hai detto, "la nostra base di codice non si presta a test facili" è il primo segno di un odore di codice. Scrivere test unitari significa in genere scrivere codice in modo diverso per renderlo più testabile. Questa è una buona cosa a mio avviso, poiché ciò che ho visto negli anni nello scrivere codice per cui ho dovuto scrivere test, mi ha costretto a proporre un design migliore.

Non lo so. Molti posti non effettuano test unitari, ma la qualità del codice è buona. Microsoft fa unit test, ma Bill Gates ha presentato una schermata blu alla sua presentazione.

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 di unit test 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 vorrei tornare al "vecchio" modo.

Come il primo sviluppo del test ha cambiato la mia vita

Sì - Il test unitario merita sicuramente lo sforzo, ma dovresti sapere che non è un proiettile d'argento. Il test unitario funziona e dovrai lavorare per mantenere il test aggiornato e pertinente come modifiche al codice, ma il valore offerto vale lo sforzo che devi fare. La capacità di refacturing con impunità è un enorme vantaggio in quanto puoi sempre convalidare la funzionalità eseguendo i test dopo qualsiasi codice di modifica. Il trucco è non rimanere troppo impiccati sull'unità di lavoro che stai testando o su come stai requisiti per i test di ponteggi e quando un test di unità è davvero un test funzionale, ecc. La gente discuterà di queste cose per ore alla fine e la realtà è che qualsiasi test che fai come il tuo codice di scrittura è meglio che non farlo. L'altro assioma riguarda la qualità e non la quantità - ho visto basi di codice con 1000 ' s di test che sono essenzialmente insignificanti in quanto gli altri non testano davvero nulla di utile o qualcosa di specifico del dominio come le regole aziendali, ecc. del dominio particolare. Ho anche visto codebase con una copertura del codice del 30%, ma i test sono stati rilevanti, significativi e davvero fantastici in quanto hanno testato la funzionalità principale del codice per cui è stato scritto ed hanno espresso come dovrebbe essere usato il codice.

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

Di recente ho vissuto la stessa identica esperienza sul mio posto di lavoro e ho scoperto che la maggior parte di loro conosceva i vantaggi teorici, ma che dovevano essere venduti in modo specifico sui vantaggi, quindi ecco i punti che ho usato (con successo):

• Risparmiano tempo quando si eseguono test negativi, in cui si gestiscono input imprevisti (puntatori null, valori fuori limite, ecc.), Poiché è possibile eseguire tutto ciò in un unico processo.
• Forniscono un feedback immediato in fase di compilazione per quanto riguarda lo standard delle modifiche.
• Sono utili per testare rappresentazioni di dati interni che potrebbero non essere esposte durante il normale runtime.

e quello grande ...

• Potresti non aver bisogno di test unitari, ma quando arriva qualcun altro e modifica il codice senza una piena comprensione, può catturare molti degli sciocchi errori che potrebbero fare.

Ho scoperto TDD un paio di anni fa, e da allora ho scritto tutti i miei progetti di animali domestici utilizzandolo. Ho stimato che il TDD impiega all'incirca lo stesso tempo di un progetto quanto lo serve per metterlo insieme, ma ho una così grande fiducia nel prodotto finale che non posso fare a meno di provare un senso di realizzazione.

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

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

Una cosa che nessuno ha ancora menzionato è l'impegno di tutti gli sviluppatori a eseguire e aggiornare effettivamente qualsiasi test automatizzato esistente. I test automatici a cui si ritorna e che si riscontrano interrotti a causa di nuovi sviluppi perdono molto del 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 impiegato per aggiornarli è solo uno spreco.

Convincere gli scettici a non distruggere il lavoro svolto dagli altri nei test unitari è molto più importante per ottenere valore dai test e potrebbe essere più semplice.

Trascorrere ore ad aggiornare i test che si sono interrotti a causa delle nuove funzionalità ogni volta che si aggiorna dal repository non è né produttivo né divertente.

Se si utilizza NUnit, una demo semplice ma efficace consiste nell'eseguire le proprie suite di test di NUnit. Vedere una vera suite di test che fornisce un codice a un allenamento vale più di mille parole ...

I test unitari aiutano molto in progetti 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. Questo riduce molto le istanze di dover sedersi e modificare i pollici in attesa che qualcun altro risolva un bug in cui si è registrato o che si preoccupi di ripristinare le modifiche in modo da poter lavorare. È anche immensamente prezioso nel refactoring, quindi puoi essere sicuro che il codice refactored superi tutti i test eseguiti dal codice originale.

Con la suite di unit test è possibile apportare modifiche al codice lasciando intatte le altre funzionalità. È un grande vantaggio. Usi Sutie unit test e suite di test di regressione quando finisci di scrivere nuove funzionalità.

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