Quando si dovrebbe smettere di testare l'unità

Question

Spesso posso identificare molte aree che sono ben incapsulate e facilmente testate da unità, ma trovo anche un sacco di codice in cui il testing delle unità non sembra funzionare bene - tipicamente accesso ai dati e l'interfaccia utente. Non importa quale "tecnica" di test unitario provo, io tendo a scoprire che in questi luoghi non è solo un grande sforzo per creare test unitari funzionanti, ma questi test tendono ad essere molto fragili e in realtà non testano molto.

A che punto ti fermi e decidi che i vantaggi dei test unitari non valgono il costo?

Answer 1

Quando è possibile fornire un valore migliore facendo qualcos'altro.

Answer 2

Quando non c'è tempo nel piano del progetto e il tempo viene speso per trovare modi di test piuttosto che lavorare verso l'obiettivo del progetto.

Answer 3

Se si dispone dell'accesso ad alcuni dati in tempo reale, è possibile utilizzarlo per il test dell'unità. anche tu puoi usare generatori di dati e dati casuali. I test unitari ti danno solo un certo livello di sicurezza sul fatto che non creerà problemi in futuro. Se si è sicuri con il test si può interrompere l'unità di test

Answer 4

tendo ad utilizzare liberamente l'modello e persistenza dei dati. test del modello è obbligatorio. L'interfaccia utente (applicazione desktop, applicazioni web, interfaccia a riga di comando, ecc.) È difficile da testare, quindi scrivo il test solo in rare circolazioni.

Answer 5

Mi piace il titolo della domanda. A parte questo, penso che sia un dupe di Is there such a thing as excessive unit testing?

Answer 6

Direi quando hai raggiunto un livello accettabile di confidenza. Inoltre, come per il mio progetto al lavoro, abbiamo requisiti di tempo così stretti che devo testare solo determinate parti di codice (non tutte) solo per darmi un buon livello di confidenza.

Answer 7

Solitamente eseguo solo il test del modello e del controller. I test delle unità sono difficili da applicare per l'interfaccia utente, di solito preferisco testare manualmente l'app.

Se la creazione di questi test richiede più tempo del test manuale ogni volta che si può avere una regressione, il test è inutile (facile da dire, ma non da valutare ...).

Answer 8

Se è necessario interrompere i test, interrompere l'integrazione o test end-to-end. Misko Hevery di Google lo spiega molto bene here.

"Unit Testing ti dà più bang per il vostro buck "

è la citazione migliore per venire fuori dal suo articolo.

Oltre a questo, quando si dispone di copertura del codice decente e sta gestendo alcuni casi limite del codice allora è un buon momento per smettere di test di unità.

Answer 9

Per quanto riguarda i test di accesso ai dati, sono stati eseguiti test di simulazione per simulare le risposte.

Answer 10

La regola di base che seguirò è se lo sforzo di costruire il test dell'unità è più che lo sforzo di ripetutamente testare manualmente la funzionalità con il lavoro umano.

Se si guardano i progetti di test nell'edizione di Visual Studio Team per i tester, c'è un tale oggetto chiamato "test manuale" che è essenzialmente un documento di istruzioni per indicare a un umano come eseguire il test e passare manualmente esso. Alcune cose, come menzionare il test dell'interfaccia utente, o il codice per aggirare un comportamento hardware oscuro o buggy nel framework o sistema operativo o driver sottostante, sono meglio verificate dagli occhi umani.

Answer 11

Se si utilizza TDD, allora si fermano test delle unità quando tutti i test nella lista dei test sono riusciti.

In caso contrario, si smette di test di unità quando il costo di trovare più bug attraverso test delle unità supera il costo di trovare loro attraverso il vostro processo di QA. e quando hai raggiunto un livello accettabile di copertura del codice attraverso la combinazione di tutti i test.