Qual è il giusto equilibrio tra test unitari e funzionali in una tipica applicazione web?

Question

I test unitari sono più economici da scrivere e gestire, ma non coprono tutti gli scenari. Qual è il giusto equilibrio tra loro?

Answer 1

Mi piace Quadrante di Brian Marick su test automatizzati in cui le distinzioni sono il business rispetto alla tecnologia e il supporto alla programmazione rispetto al prodotto di critica.

Con quel quadro la domanda di equilibrio diventa, di cosa ho bisogno adesso?

Answer 2

è importante distinguere tra l'intento e la portata di questi due tipi di test:

• a unit test in genere testano una funzionalità specifica a livello di modulo / classe , per esempio create-X, update-Y, foo-the-bar, compact-the-whizbang, ecc. Una classe può avere più unit test

• a test funzionale , chiamato anche "test di accettazione", in genere verifica un scenario del caso d'uso dall'interfaccia più esterna fino alla fine dell'elaborazione, ad es dall'interfaccia utente al database e viceversa, dal processo di input all'utilità di notifica, ecc.

questi due tipi di test sono non intercambiabili e in generale disgiunti . Quindi l'idea di trovare un "equilibrio" tra loro non ha senso. O ne hai bisogno o no.

se ti riferisci alla facilità di codifica di ogni tipo di test nel tuo framework di test, questa è una domanda diversa, ma l'uso del framework (diciamo NUnit vs. un user-bot) non cambia il tipo / natura del test.

il migliore "bilancio", in generale, sarebbe quello di testare l'unità per la fiducia e la completezza e test funzionale per l'accettazione del cliente

Answer 3

Concordo con Steven Lowe sul fatto che non vi è alcun compromesso tra test unitari e test funzionali, poiché vengono utilizzati per scopi molto diversi.

I test unitari riguardano la verifica di metodi e tipi e anche i test di regressione. I test funzionali riguardano test funzionali, di scenario e di fattibilità. Secondo me, non c'è quasi nessuna sovrapposizione,

Se aiuta, ecco le mie categorie di test.

Gli sviluppatori iniziano dall'interno e lavorano verso l'esterno, concentrandosi sul codice:

• Asserzioni: verifica il flusso e le strutture di dati
• Debugger: verifica il flusso di codice e i dati
• Test unitari: verifica ogni funzione
• Test di integrazione: verifica i sottosistemi
• Test di sistema: verifica la funzionalità
• Test di regressione: verifica che i difetti rimangano corretti
• Test di sicurezza: verifica che il sistema non possa essere penetrato facilmente.

I tester iniziano dall'esterno e lavorano verso l'interno, concentrandosi sulle funzionalità:

• Test di accettazione: verifica i requisiti dell'utente finale
• Test degli scenari: verifica le situazioni del mondo reale
• Test globali: verifica input fattibili
• Test di regressione: verifica che i difetti rimangano corretti
• Test di usabilità: verifica che il sistema sia facile da usare
• Test di sicurezza: verifica che il sistema non possa essere penetrato facilmente
• Copertura del codice - test del codice non trattato
• Compatibilità - con versioni precedenti
• Alla ricerca di stranezze e bordi grezzi.

Gli utenti finali lavorano dall'esterno e di solito hanno poca attenzione:

• Test di accettazione: verifica i requisiti dell'utente finale
• Test degli scenari: verifica le situazioni del mondo reale
• Test di usabilità: verifica che il sistema sia facile da usare
• Alla ricerca di stranezze e bordi grezzi.

Answer 4

Sull'app su cui sto lavorando al momento, ci sono probabilmente unità 10: 1 per i test funzionali. Il test unitario funziona semplicemente come il recupero di entità dal DB, i test di gestione degli errori per la connettività di rete / db, ecc. Queste cose sono veloci - minuti o meno e vengono eseguite dagli sviluppatori ogni giorno.

test funzionali mentre meno tendono ad essere l'approccio del lavello della cucina - può l'utente completare l'ordine, ecc. tendono a coprire il dominio aziendale. La fine delle cose è gestita da analisti e operazioni aziendali - purtroppo per noi, spesso a mano. Queste cose richiedono settimane per l'esecuzione e in genere per finalizzare un ciclo di rilascio.

Answer 5

Il mio progetto attuale è circa il 60% di copertura dei test unitari e tutte le storie degli utenti hanno una copertura felice delle storie degli utenti nei test del selenio, alcune hanno una copertura aggiuntiva.

Ne parliamo continuamente: c'è davvero qualche motivo per spingere la copertura unit-test di scenari sempre più assurdi per una copertura molto più elevata?

L'argomento è che l'espansione dei test di selenio aumenta la copertura dei test su cose che hanno valore commerciale. Il cliente si preoccupa davvero dei casi di test unit unit che potrebbero non riuscire?

Quando si diventa bravi nei test al selenio, il costo per scrivere nuovi test con valore commerciale diminuisce. Per noi sono semplici quanto i test unitari.

Il costo di runtime è un altro problema. Abbiamo un piccolo gruppo di scatole che eseguono questi test continuamente.

Quindi tendiamo a favorire maggiormente i test Web, probabilmente perché siamo diventati bravi a scriverli e forniscono un valore commerciale innegabile.

Answer 6

Inizialmente mi sono fortemente orientato verso la preferenza di test unitari rispetto a test funzionali / di collaudo a causa del fattore di costo iniziale dei test di collaudo. Tuttavia, nel corso del tempo ho cambiato la mia filosofia e ora sono un forte sostenitore della scelta dei test di collaudo ove possibile e dell'utilizzo dei test unitari solo quando i test di collaudo non sono in grado di soddisfare le mie esigenze.

Il razionale di base dietro la scelta dell'accettazione rispetto ai test unitari è lo stesso del razionale di base per codice SOLID . L'implementazione dovrebbe essere in grado di cambiare drasticamente con refactoring ecc., Ma tutti i casi aziendali - test di accettazione - dovrebbero essere in grado di rimanere invariati e dimostrare un comportamento accettabile del sistema (test superati). Con i test unitari c'è spesso un forte accoppiamento naturale tra test e codice di implementazione. Anche se è un codice di test, è comunque da evitare il codice e l'accoppiamento forte come sappiamo. Scegliendo i test di accettazione, sei spesso guidato nella spirale del successo per creare api ben pianificati e consumabili disaccoppiati che consentono alla tua implementazione di cambiare dietro le quinte senza forzare i test a cambiare. Inoltre, i pensieri sull'implementazione dello sviluppatore sono in linea con i pensieri sul comportamento del sistema aziendale. Alla fine trovo che tutto ciò sia migliore per gli affari e per la soddisfazione dei programmatori.

Da un punto di vista teorico mi chiedo spesso se un pezzo di codice non può essere testato tramite un test di accettazione perché dovrebbe esistere quel pezzo di codice? IE: se non fa parte di uno scenario aziendale valido, quel codice aggiunge valore o è attualmente e rimarrà solo a costo?

Inoltre, se commentate / documentate bene i test di accettazione, tali commenti / documenti sono generalmente il linguaggio più attuale e accurato del sistema, che di solito vi consentirà di evitare altri approcci di documentazione meno preziosi. I test unitari non si prestano a quella forma di "termine commerciale" comunicazione.

Infine, non ho formato questo punto di vista solo dal mio sviluppo personale, ha avuto successo con un paio di team di progetto diversi nel mio "molto aziendale" ambiente di lavoro.

JB http://jb-brown.blogspot.com

Answer 7

I test dovrebbero essere eseguiti rapidamente e aiutare a localizzare i problemi. I test unitari ti permettono di farlo testando solo il modulo in questione. Tuttavia, è possibile eseguire test funzionali / di integrazione / accettazione per eseguirli sufficientemente rapidamente nella maggior parte degli scenari Web.

Answer 8

Una volta ho letto che un test unitario è un "requisito eseguibile", il che ha perfettamente senso per me. Se il tuo test non è focalizzato sulla dimostrazione di un requisito aziendale, non è davvero utile. Se hai requisiti dettagliati (e questo è il test dell'acido), dovrai scrivere una serie di test unitari per esercitare ogni possibile scenario che a sua volta assicurerà l'integrità degli algoritmi e della logica della struttura dei dati. Se stai testando qualcosa che non è un requisito ma sai che deve essere vero affinché il test passi, è più che probabile che manchi i requisiti.