Test delle unità su cosa il programma NON dovrebbe fare

Question

Questa domanda riguarda la misura in cui ha senso testare le unità.

Ho scritto un programma tipico che aggiorna un database con le informazioni che arrivano nei messaggi XML. Ho pensato ai test unitari di cui aveva bisogno. Il programma inserisce o aggiorna i record in base a regole complicate, che generano molti casi diversi. In un primo momento, ho deciso di testare le seguenti diverse condizioni per ogni caso:

• il numero necessario di record aggiunto
• I campi di record inseriti e aggiornati sono riempiti correttamente
• No records esistenti, ma irrilevante per i dati caricati sono stati modificati

Mi sembrava che il terzo tipo di test avesse davvero senso. Ma presto ho scoperto che non è così facile da implementare, perché è effettivamente necessario fare una specie di snapshot del database e quindi confrontarlo con quello modificato. Ho iniziato rapidamente a essere infastidito dal fatto che avevo bisogno di scrivere tali test per diversi casi di modifica del database, mentre questi test non erano molto preziosi e informativi in ​​termini di specifiche e design del codice di produzione.

Poi ho pensato, forse, sto testando troppo? E se no, quindi se ho prova che il programma non modifica i record irrilevanti, allora perché non provo che:

• non modifica altri database
• non elimina i file sui dischi
• NON invia e-mail a Santa Klaus?

Mi sono completamente confuso su dove tracciare il limite. Dove lo disegneresti?

UPDATE

ho letto molti suggerimenti utili nelle risposte e segnato uno come la soluzione, perché ha le idee più utile per me, ma ancora non è chiaro per me come eseguire il test correttamente gli aggiornamenti del database. Ha senso verificare che il programma non cambi troppo? E se è così, allora quanto accuratamente?

Answer 1

Se si dovesse una quantità infinita di tempo e risorse (e niente di meglio da fare con loro :-), sarebbe bene (anche se ancora piuttosto noiosa per lo più) per testare tutto che è possibile testare. Tuttavia, viviamo nella vita reale dove abbiamo pressioni sul tempo e sulle risorse, quindi dobbiamo dare la priorità ai nostri sforzi di test. Kent Beck ha riassunto bene come "prova tutto ciò che potrebbe eventualmente rompere".

Si noti che questo è vero anche per l'integrazione/system/test di accettazione in una certa misura, ma la differenza è che unit test sono test white box, quindi si suppone di conoscere sia

• che cosa il vostro codice di dovrebbe do, e
• quello che in realtà ha scritto.

Ciò consente di concentrare gli sforzi delle unità sui problemi reali. Il tuo metodo scrive i dati su un flusso di output? Sì? Quindi ha perfettamente senso testare ciò che è (non) scritto lì. Il tuo metodo fa qualcosa relativo alla spedizione? No? Quindi non ha senso verificare che non invii una mail a Babbo Natale.

/prove di collaudo del sistema sono diverse in quanto

• sono prove di scatola nera, in tal modo il tester (dovrebbe) non fare ipotesi su come il programma è effettivamente attuato, e
• si prova un intero complesso programma dove c'è molta più possibilità che parti diverse interagiscano in modi inaspettati (e potenzialmente indesiderati).

quindi ha più senso per gettare una rete più ampia di test, per testare gli scenari più "folli" e verificare più delle cose che il programma dovrebbe non fare.

Answer 2

Disegnate la linea nel punto in cui i test smettono di essere utili e non vi dicono più qualcosa sul codice .

È utile sapere che il tuo software non invia email a Santa? No. Allora non provare per quello.

Sapere che il livello di accesso ai dati sta facendo la cosa giusta è utile - che gli aggiornamenti giusti stanno accadendo.

Answer 3

È più facile testare cosa dovrebbe fare, quindi cosa non dovrebbe. A parte alcune eccezioni:

• Sicurezza: l'utente con accesso "admin locale" non dovrebbe essere in grado di vedere le pagine "global admin".
• Casi di bordo: il 30 febbraio non viene analizzato come 2011-02-30
• roba che è esplicitamente nelle specifiche/analisi "Gli utenti possono visualizzare la valutazione media, ma non i singoli record".

Answer 4

Penso che un buon test di unità sia quello che verifica tutte le linee di codice di una funzione e tutti i requisiti/casi d'uso coperti.

Per funzioni semplici di solito significa testare la funzionalità corretta e gli errori che gestisce e verificare che si tratti del comportamento previsto.

Vorrei tracciare una riga per il test dell'unità, vorrei anche tenere a mente le altre preoccupazioni che avete e prendervi cura di loro nei test di sistema o di integrazione. Ciò significa testare l'applicazione in qualsiasi numero di scenari e quindi verificare che il database sia ancora corretto, nessun file è stato eliminato e Babbo Natale non ha ricevuto alcuna e-mail. Puoi testare qualsiasi numero di possibilità, ovviamente le cose più irragionevoli che controlli, più tempo perdi.