Test unitari o test funzionali?

Question

Recentemente ho sentito parlare di Functional Testing su Unit Testing.

Capisco che Unit Testing testa ognuna delle possibilità di un dato pezzo di codice dalla sua forma più atomica. Ma per quanto riguarda Functional Testing?

Questo mi sembra un test solo se il codice funziona, ma è affidabile quanto il test di unità?

Mi è stato detto che c'erano due scuole di pensiero per la questione. Alcune preferirebbero il test unitario, altri test funzionali.

C'è qualche buona risorsa, link, libri, riferimenti o qualcuno di voi che può spiegare e approfondire il mio percorso sull'argomento?

Grazie!

Answer 1

La risposta di Jason è corretta. Diversi tipi di test hanno scopi diversi e possono essere stratificati per ottenere i migliori risultati (buon design, conformità alle specifiche, difetti ridotti).

• test delle unità = unità di progettazione (con Test-Driven Development, o TDD)
• di testing di integrazione = fare tutti i pezzi di lavorare insieme
• clienti test di accettazione = vuol soddisfare le esigenze del cliente
• test manuale = spesso copre l'interfaccia utente; tester dedicati possono trovare ciò che manca l'automazione
• test di carico = quanto bene fa il sistema esegue con quantità realistiche dei dati

V'è una certa sovrapposizione tra queste categorie; i test unitari possono specificare il comportamento, ad esempio.

E ce ne sono altri; per più di quanto la maggior parte della gente tenga a sapere, vedi Software Testing.

Un punto perso è che il test dell'unità sta testando i pezzi del codice in isolamento. Ad esempio, buoni test unitari non colpiscono il database.Questo ha due vantaggi: rende i test eseguiti velocemente, quindi li eseguirai più spesso, e ti costringe a scrivere classi liberamente accoppiate (miglior design).

Hai chiesto risorse; Raccomando il libro di Roy Osherove The Art of Unit Testing with Examples in .NET. Mentre nessun libro è perfetto, questo dà molti ottimi consigli su come scrivere buoni test.

EDIT: E per scrivere test su software esistenti, niente batte il libro di Michael Feathers Working Effectively with Legacy Code.

Answer 2

Test unitari rispetto a test funzionali non è uno xor, ma piuttosto uno and. I test unitari riguardano le unità di test in isolamento mentre i test funzionali riguardano il test dell'integrazione completa (tutte le unità funzionano correttamente insieme?).

Entrambi sono componenti necessari di buone pratiche di ingegneria del software.

Answer 3

C'è un posto per entrambi nella maggior parte dei lavori di sviluppo.

L'unità di test è lì per testare piccole unità di codice, per vedere che funzionano come previsto.

I test funzionali servono a verificare che la funzionalità complessiva del sistema sia quella prevista.

Sono a livelli diversi ed entrambi dovrebbero essere utilizzati.

Answer 4

Test di unità e test funzionali hanno due risultati diversi.

Unit Testing verifica che un piccolo pezzo di codice funzioni come previsto. Di solito lo sviluppatore lo fa per assicurarsi che il codice funzioni correttamente. Di solito sono automatizzati anche da un framework di test.

Test funzionali verifica che una funzionalità funzioni come previsto passando attraverso un determinato percorso attraverso il programma. Di solito vengono eseguiti da una persona sul software, assicurando che il programma funzioni nel modo previsto per l'utente. In quanto tale, è di livello superiore e quindi testa più unità contemporaneamente.

Penso che entrambi siano importanti. Se hai risorse limitate, però, e devi scegliere/scegliere le tecniche, e penso che dipenda dai prodotti che crei, ma per quello che faccio (prodotti di controllo automobilistici usati dall'uomo attraverso alcuni pulsanti) i test funzionali sono più importanti. Controlla e garantisce che quando l'utente ottiene il prodotto, fa ciò che deve fare. Ciò non significa che dovremmo rinunciare ai test unitari, ma se il push-to-to-shove è funzionale, il più importante è garantire un'esperienza utente ottimale e portare il prodotto fuori dalla porta.

Se produci, ad esempio, un motore di database (o qualche altro prodotto che non è necessariamente rivolto all'utente), il test delle unità potrebbe essere ciò che dovresti veramente fare.

Answer 5

• Test unità = livello più basso, granulare.
• Test funzionale = livello modulare, modulare.
• Test di integrazione = livello di applicazione superiore.
• Factory Acceptance Test = vedono tutto il lavoro
• Site Acceptance Test = vedono tutti non riescono :)

Tutto quanto sopra sono utili ma non sono mutuamente esclusive. Dovresti fare la maggior parte di loro, ma la quantità di tempo che spendi per ogni parte dipende dai risultati che ottieni da loro, tutto qui. Se il tuo codice è troppo modulare per essere facilmente testato sull'unità, dedica i tuoi sforzi ai test funzionali. Se stai scrivendo una libreria di piccoli componenti, trascorri il tuo tempo su unità che li testano, e se stai scrivendo sistemi di controllo per missili militari dovresti assolutamente sottoporli al collaudo del sito (poiché le esplosioni anche quando falliscono sono divertenti :))

Answer 6

Il test delle unità verifica le unità del codice (metodi, ecc.) Per assicurarsi che facciano ciò che ci si aspetta.

Test funzionali verificano la progettazione del sistema per assicurarsi che i pezzi interagiscano correttamente. Se scrivi un comando che accetta e int e restituisce una stringa e testala completamente, puoi essere certo che funzioni. Ma se non si hanno test di sistema, non si può mai notare che il resto del codice pensa di poter accettare un valore nullo ma non può farlo.

Entrambi i tipi di test sono importanti.

edit: Per aggiungere una visione leggermente diversa da quella che gbjbaanb detto: prova

• Unità = il mio codice funziona
• Test funzionale = il mio progetto funziona
• test di integrazione = il mio codice sta usando il 3 ° roba di partito correttamente (database, ecc.)
• Test di collaudo in fabbrica = il mio sistema funziona
• Test di accettazione del sito = il tuo codice fa schifo, questo non è assolutamente quello che ho chiesto!?!

Answer 7

Il test funzionale, chiamato anche System testing, ha lo scopo di testare il sistema completo e verificare che i requisiti funzionali siano soddisfatti.

Unit testing ha lo scopo di testare le "unità", ovvero le funzioni oi metodi che il sistema costruisce da in isolamento. A volte è chiamato test dello sviluppatore. Il test delle unità può essere difficile dopo il fatto, ecco perché TDD scrive il test prima del codice.

Questi sono complementare poiché le unità possono funzionare in modo indipendente e non quando sono integrate tutte insieme, oppure possono superare i test di unità e non soddisfare tutti i requisiti del prodotto.

Answer 8

Un test di unità verifica un pezzo di codice e conferma per un programmatore che un altro pezzo di codice sta facendo quello che dovrebbe. In Test Driven Development, il test unitario viene scritto per primo e osservato fallire, prima che il codice sia scritto causando il passaggio del test. I programmatori sono interessati ai test delle unità. Le unit test sono veloci da eseguire.

Un test di funzionalità verifica i requisiti della scatola nera e dimostra che è stata implementata una funzionalità utente. Ad esempio, se premo il grande pulsante rosso, la campana inizia a squillare. Il test funzionale potrebbe non essere nemmeno il test del codice. Forse c'è un processo meccanico che fa suonare la campana dopo aver premuto il pulsante. I clienti sono interessati ai test funzionali in quanto confermano che un processo di alto livello se funziona in modo comprensibile. Sono spesso lenti da eseguire.