Quali sono i pro e i contro dei test manuali dell'unità rispetto ai test automatizzati delle unità?

Question

È possibile ottenere i vantaggi e gli svantaggi di Test unità manuale confrontare con il processo automatizzato.

Answer 1

Strana domanda: il test dell'unità dovrebbe essere automatico, quindi ripetibile e facile da eseguire. Per molti (me compreso) "test unitario manuale" è una contraddizione in termini.

Il test manuale può essere utile nei casi in cui non è possibile eseguire test automatici. Questi di solito non sono al livello di test unitario, ma più alti - ad es. test di integrazione, GUI, stress ecc.

Con i test di unità, si stanno testando piccoli pezzi del codice (in genere metodi/classi individuali) alla volta. I test sono scritti nel codice stesso, quindi possono (quasi sempre) essere eseguiti automaticamente da un framework di test delle unità.

Aggiornamento: ora che si dà un contesto più concreto alla tua domanda, è più facile dare una risposta concreta :-)

Sono convinto di dire che unit test automatizzati praticamente sempre paga per loro molti volte nel corso della vita di un progetto SW. Impostarli è più costoso rispetto ai test manuali, ma più li esegui, più tempo risparmia e più presto riceverai feedback su dove il tuo codice viene infranto da nuove modifiche.

La copertura di codice legacy con unit test non è sicuramente semplice, ma se il prodotto è prezioso per la vostra azienda e si prevede che continui per anni, è comunque uno sforzo degno. Soprattutto perché nella vita reale, un sistema di produzione tende a sopravvivere alla sua durata prevista.

Un aspetto è, si "prova a controllare tutti i percorsi di codice che abbiamo scritto" - con i test unitari automatizzati combinati con uno strumento di copertura del codice, è possibile vedere automaticamente - spesso direttamente all'interno dell'IDE, se lo strumento di copertura è integrato bene - quali percorsi di codice non sono coperti dai tuoi ultimi test unitari.

Io raccomando Working Effectively with Legacy Code - contiene una ricchezza di preziose conoscenze su come scrivere test di unità per codice legacy ingarbugliato, scritto male.

Answer 2

Penso che l'unica vera risposta alla tua domanda sia non importa, perché devi avere sia.

I test di unità automatizzati consentiranno ai vostri sviluppatori di codificare i test che convalidano automaticamente il codice in base allo delle loro specifiche. Poiché sono automatizzati, possono essere ripetuti più e più volte con variazioni minime o nulle. Per definizione, questi test unitari sapranno come funziona il software, sotto il cofano, e come tale possono essere considerati come test white box - i test sono a conoscenza di alcuni se non di tutto il codice sottostante.

I test manuali, d'altro canto, rivelano problemi dal punto di vista degli utenti. Avrai la possibilità di scoprire quali errori possono essere incontrati da entità che non hanno familiarità con il codice e la struttura sottostante, così come se ci sono problemi riguardo all'usabilità del tuo programma. Questo è considerato come test scatola nera.

Answer 3

"Test unità manuale" è praticamente impossibile. Il test unitario è definito come test di piccole unità di codice isolate. Non puoi farlo davvero manualmente.

Ora, se si sta parlando di test di integrazione, che è una questione diversa:

Pro test di integrazione manuale:

• tester sono più economici rispetto agli sviluppatori
• tester possono regolare in modo intelligente la prova i cambiamenti nell'applicazione - non sono intrinsecamente fragili come i test automatici
• I tester possono individuare i bug che un test automatico potrebbe perdere (come missi ng o valori errati per i quali non sono stati testati esplicitamente o problemi di layout)
• Non richiede un software di test aggiuntivo che può essere costoso e/o richiedere molto tempo per apprendere
• Sempre possibile; non ci sono requisiti tecnici che devi soddisfare
• Puoi solo iniziare; i costi iniziali per eseguire un singolo test sono molto più bassi rispetto all'impostazione e all'implementazione di un test automatizzato.

CON test di integrazione manuale:

• si deve pagare un essere umano ogni volta che li fate. A lungo termine, questo è molto, molto costoso.
• Test di regressione completa dopo correzioni di bug è praticamente impossibile (troppo costoso).
• Ciò significa che devi essere molto prudente con le modifiche in ritardo nel ciclo di sviluppo e grandi cambiamenti in generale. Nessun refactoring costante: meglio vivere con un codice erroneo rispetto al rischio di effetti collaterali catastrofici.
• Devi pianificare molto attentamente quando eseguirai il test per ottenere il massimo valore in denaro. In una certa misura, dovrai adeguare le tue pratiche di sviluppo per riflettere questo.

Tutto sommato, è meglio avere entrambe le test di integrazione manuali e automatizzati; questi possono a volte integrarsi a vicenda, in quanto alcune cose possono infatti essere più facili da testare in modo automatico, mentre altre non possono essere automatizzate affatto.