Quanto lontano per andare con i test unitari

11

Una domanda posta molte volte prima ma con uno sviluppo specifico del mvc di slant twds.

Sono stato un bravo ragazzo e ho codificato tutte le azioni del mio controller con corrispondenti test unitari che sono stati fantastici (se un po '[leggi un LOT] ripetitivo a volte). Per essere onesti, in realtà ho creato un piccolo modello T4 per scrivere la maggior parte delle ossa nude dei test di unità intiali e poi ottimizzato come appropriato per l'utilizzo. Devo ammettere di non essere abbastanza sicuro su come gestire i test nelle viste che contengono partialviews - ma questa è una storia per un'altra domanda.

Ora, la parte più difficile per me da decidere è la profondità della copertura nel mio livello di servizio. Il motivo è che alcuni dei miei metodi di servizio (nel bene o nel male) eseguono effettivamente una varietà di query linq che forniscono informazioni discrete alla logica successiva all'interno del metodo. So che potrei (dovrei ??) rompere questi metodi verso il basso per chiamare solo la logica richiesta per ogni istruzione linq e quindi applicarli all'interno del metodo. Tuttavia, in molti casi, non c'è mai alcun riutilizzo delle "funzioni" di linq e quindi si ritiene che questo ridicherebbe il codice a un livello troppo alto.

Quello che sto chiedendo è, con logica complessa che si verifica all'interno di un metodo, è 'abbastanza buono' avere un metodo di test che asserisca semplicemente il risultato richiesto e / o l'errore previsto, o ogni linea logica dovrebbe essere simultanea e testata pure. per come la vedo io, per fare il test correttamente, quindi la logica del metodo (riga per riga) dovrebbe avere anche una sorta di copertura. Ciò tuttavia (secondo la mia ingenua opinione) potrebbe portare a un ciclo infinito di tentativi di mantenere il test e il metodo implementato così strettamente allineato (che so che dovrebbero essere) per creare un'industria di cottage nei test stessi.

So che la mia domanda potrebbe offendere alcuni dei devoti del TDD che vedranno questo come un gioco da ragazzi. Non essendo nel campo TDD, questo è un 'sì di buon senso' per me, da qui la domanda.

btw - aveva controllato per idee:

link

guarda ora i downvotes costanti:)

[modifica] - a beneficio del singolo (ben al momento single !!) elettore "vicino". questa domanda è non soggettiva. Sto cercando il consenso su un argomento molto focalizzato. Non sto cercando di suscitare passioni negative, non sto cercando di mettere in luce difetti nella tecnologia - sono un fan enorme. Quindi, per favore, invia un cortese commento per il mio beneficio se voto per chiudere in quanto potrebbe aiutarmi a ristrutturare la domanda se c'è ambiguità o disinformazione. questa domanda potrebbe beneficiare di una grossa fetta della popolazione di mvc.

grazie !!

jim

    
posta jim 07.03.2011 - 12:36
fonte

4 risposte

4

Prima di tutto ciò di cui stai parlando non sembra del tutto simile a TDD. TDD implica un primo approccio di prova che riguarda la guida del design del sistema seguendo lo schema di Test- > Code- > Refactor . Quindi forse il tuo primo problema è lo scopo dei tuoi test, li stai scrivendo mentre codifichi? Se è così, mi aspetterei che praticamente tutta la logica del test si riferisca a qualche test unitario. L'alta copertura del codice è quindi un risultato indiretto dell'applicazione del TDD.

Quando stai facendo TDD scrivi abbastanza codice di prova per motivare il codice che vuoi scrivere. Assicurati anche che il test fallisca prima. Fondamentalmente chiediti cosa è necessario fare questo metodo. Quindi lo codifichi, ma quel tanto che basta per fare passare il test, se non è quello che stai cercando, allora scrivi test aggiuntivi e poi rifatta il metodo.

La copertura del codice dopo il fatto non è un metodo efficace per misurare la tua adesione a TDD, anche se di solito trovi una copertura di codice molto alta nel codice scritto usando TDD do al fatto che tutto il codice dovrebbe essere stato motivato da qualche test .

I test TDD servono sia a guidare la progettazione che a documentare e spiegare il design agli altri in un linguaggio semplice (quindi il modo in cui nominali i test è molto importante).

Tuttavia nessuno di questi sconvolgimenti risponde alla tua domanda direttamente, quindi ti dirò semplicemente che dovresti mirare a una copertura del codice del servizio (non UI) piuttosto elevata, specialmente laddove esiste una logica non trival, e ancora meglio se i test sono scritti prima ;-). Il fatto è (anche se alcuni potrebbero non essere d'accordo) che più test sono generalmente migliori. Molti progetti open source di alta qualità hanno molto più codice di test rispetto al codice in esecuzione.

Inoltre, i test dovrebbero essere scritti ogni volta:

  1. Stai scrivendo un nuovo codice, i test dovrebbero guidare e documentare la tua progettazione e spiegare le tue supposizioni su cosa dovrebbe fare il codice. Il dovrebbe essere scritto prima di codice.

  2. Hai trovato un bug, un test fallito dovrebbe dimostrare il bug. Quando il bug è corretto, il test dovrebbe passare.

  3. Si modifica il codice in un modo che modifica la natura di ciò che fa un metodo o una classe (anche se molti test falliscono quando una zona del codice cambia questo potrebbe indicare test fragili). Ciò mantiene i test che documentano correttamente il codice.

Personalmente, ho scoperto che l'apprendimento del TDD è una sfida interessante e ci vuole tempo per sviluppare un buon "sentimento" per esso. Pratica, pratica, pratica è stato il modo migliore per imparare per me. Questo e leggere il codice di prova da progetti open source e ora anche contribuire a loro durante la scrittura di nuovi test con le mie modifiche.

    
risposta data 07.03.2011 - 17:25
fonte
0

È ovvio che testare solo il valore di ritorno di un metodo è meno potente di testare tutti i rami al suo interno. Ingressi alternativi non saranno garantiti comportamento corretto.

D'altra parte, potresti non avere abbastanza tempo o pazienza per testare tutto.

Quello che puoi fare è decidere quanta parte del codice vuoi coprire con i test (80-90% o qualsiasi altra cosa) e applicarla usando strumenti automatici che ne verificano la verifica.
Un "ciclo infinito" di test di scrittura avverrà solo se anche il ciclo di scrittura del codice non finirà mai:)

    
risposta data 07.03.2011 - 12:56
fonte
0

Quanto vuoi essere sicuro che il tuo codice funzioni correttamente? Il test delle unità è semplicemente uno strumento nella borsa del programmatore per verificare che l'implementazione esegua ciò che le specifiche dicono che deve fare. Probabilmente non hai bisogno di una copertura del 100%, ma dovresti scrivere dei test delle unità per coprire le parti più critiche del tuo codice. È sempre bene assicurarsi che i tuoi metodi funzionino bene insieme, non solo da soli, e dovresti quindi provare a scrivere alcuni test che coprono alcune delle tue "linee di logica" più critiche.

    
risposta data 07.03.2011 - 14:36
fonte
0

Esecuzione di test unitari con la copertura del codice attivata in Visual Studio dovrebbe darti una buona indicazione (e grafica) del livello di copertura del tuo codice.

Se non stai utilizzando il framework MSTest integrato potresti dover guardare un prodotto di copertura del codice di terze parti per lavorare con NUnit o seguire le istruzioni qui: link

    
risposta data 07.03.2011 - 17:30
fonte

Leggi altre domande sui tag