Fino a che punto andare con i test unitari

Una domanda posta molte volte prima ma con uno sviluppo inclinato specifico di mvc.

Sono stato un bravissimo ragazzo e ho codificato tutte le azioni del mio controller con corrispondenti test di unità che è stato grandioso (se un po '[leggi un sacco] ripetitivo a volte). Ad essere sincero, in realtà ho creato un piccolo modello T4 per scrivere la maggior parte delle ossa nude dei test delle unità iniziali e quindi ottimizzato in base all'utilizzo. Devo ammettere di non essere del tutto sicuro di come gestire i test in viste che contengono viste parziali - ma questa è una storia per un'altra domanda.

Ora, la parte difficile per me da decidere è quanto profonda dovrebbe essere la 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 quindi informazioni discrete alla logica successiva all'interno del metodo. So che potrei (dovrei ??) abbattere questi metodi per chiamare solo la logica richiesta per ogni istruzione linq e quindi applicarli all'interno del metodo. Tuttavia, in molti casi, non vi è mai alcun riutilizzo delle "funzioni" di linq e pertanto si ritiene che ciò porterebbe il refactoring del codice a un livello troppo elevato.

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

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

btw - aveva verificato questo per idee:

http://dotnetslackers.com/articles/aspnet/Built-in-Unit-Test-for-ASP-NET-MVC-3-in-Visual-Studio-2010-Part-1.aspx

guardando avanti ai fermi voti adesso :)

[modifica] - a beneficio del singolo (beh al momento singolo !!) 'chiudi' elettore. questa domanda non è soggettiva. Sto cercando un consenso su un argomento molto focalizzato. Non sto provando a suscitare passioni negative, non sto cercando di esporre difetti nella tecnologia - sono un ENORME fan. Quindi, per favore, lascia un commento educato a mio vantaggio se votare per chiudere in quanto potrebbe aiutarmi a ristrutturare la domanda se c'è ambiguità o disinformazione. questa domanda potrebbe giovare a una grande fetta della popolazione di mvc.

grazie!!

jim

Prima di tutto ciò di cui stai parlando non suona proprio come TDD. TDD implica un primo approccio di prova che riguarda la progettazione del sistema seguendo il modello Test-> Codice-> Rifattore . Quindi forse il tuo primo problema è lo scopo dei tuoi test, li stai scrivendo come codice? In tal caso, mi aspetto che praticamente tutta la logica all'interno del test si riferisca a qualche test unitario. La copertura del codice elevato è quindi un risultato indiretto dell'applicazione del TDD.

Quando fai TDD scrivi abbastanza codice di prova per motivare il codice che vuoi scrivere. Assicurati anche che il test fallisca prima. Fondamentalmente chiediti che cosa deve fare questo metodo. Quindi lo codifichi, ma quanto basta per far passare il test, se non è quello che stai cercando allora scrivi test aggiuntivi e quindi refactoring il metodo.

La copertura del codice dopo il fatto non è un metodo efficace per misurare la tua aderenza al TDD, anche se in genere troverai una copertura del codice molto elevata nel codice scritto usando TDD per il fatto che tutto il codice avrebbe dovuto essere motivato da qualche test.

I test TDD servono sia per guidare la progettazione che per documentare e spiegare la progettazione ad altri in un linguaggio semplice (quindi il modo in cui si nominano i test è molto importante).

Tuttavia, nessuna di queste confusioni risponde davvero direttamente alla tua domanda, quindi dirò solo, dovresti mirare a una copertura del codice di servizio (codice non UI) piuttosto elevata, specialmente ovunque ci sia una logica non trivalente, e ancora meglio se i test sono scritto per primo ;-). Il fatto è (anche se alcuni potrebbero non essere d'accordo) che più test sono generalmente migliori. Molti progetti open source di alta qualità hanno un codice di test molto maggiore rispetto all'esecuzione del codice.

Inoltre, i test devono essere scritti ogni volta che:

1. Stai scrivendo un nuovo codice, i test dovrebbero guidare e documentare il tuo progetto e spiegare i tuoi presupposti su cosa dovrebbe fare il codice. Dovrebbe essere scritto prima del codice.

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

3. Modifichi il codice in un modo che cambia la natura di ciò che fa un metodo o una classe (anche se molti test falliscono quando cambia un'area del codice questo potrebbe indicare dei 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 una buona "sensazione viscerale". Pratica, pratica, pratica è stato il modo migliore per imparare per me. Questo e la lettura del codice di test da progetti open source e ora anche il loro contributo durante la scrittura di nuovi test con le mie modifiche.

È ovvio che testare solo il valore di ritorno di un metodo è meno potente di testare tutti i rami al suo interno. Agli ingressi alternativi non verrà garantito un comportamento corretto.

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

Quello che puoi fare è decidere quanta parte del codice che vuoi coprire con i test (80-90% o altro) e applicarlo usando strumenti automatizzati che lo verificano.
Un "ciclo infinito" di test di scrittura si verificherà solo se anche il ciclo di scrittura di codice non finisce mai :)

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

L'esecuzione di unit test con la copertura del codice attivata in Visual Studio dovrebbe darti una buona (e grafica) indicazione di come il tuo codice è coperto.

Se non si utilizza il framework MSTest integrato, potrebbe essere necessario guardare un prodotto di copertura del codice di terze parti per lavorare con NUnit o seguire le istruzioni qui: /programming/2665799/does-vs2010-code -copertura-support-NUnit