Inserimento / rimozione e atomicità del database test di unità

Question

Inserimento / rimozione e atomicità del database test di unità

#1 da (3 voti)
#2 da (1 voti)

2

Creo il mio database di test compatto. Questo è un file SDF, incorporato come risorsa di Visual Studio. All'avvio della suite di test, questo database viene copiato in %LOCALAPPDATA% , quindi il mio test può utilizzarlo.

Il primo metodo che voglio testare è il metodo getById . Abbastanza semplice.

var response = repo.GetById(IdToFind)
Assert.IsNotNull(response);

Ora supponiamo di voler testare il metodo Remove . Questi sono i passaggi che ho scoperto:

repo.Remove(objectToRemove)
var response = repo.GetById(objectToRemove.Id) // is this a right choice?
Assert.IsNull(response);

questo mi sembra abbastanza chiaro, ad eccezione della chiamata GetById. Questo passaggio compromette l'atomicità del test?

unit-testing database

posta BAD_SEED 15.09.2014 - 16:04

fonte

2 risposte

Leggi altre domande sui tag unit-testing database

Come misurare l'accuratezza dell'algoritmo? test dei messaggi SOAP

score 3 · Answer 1

In generale, non è possibile testare ciascun metodo separatamente. Come minimo, ogni test testerà sia un costruttore che il metodo effettivamente chiamato. Per i metodi che modificano lo stato, dovrai indagare sullo stato in seguito. È possibile fare in modo che il test dipenda dai dettagli dell'implementazione esaminando lo stato interno dell'oggetto oppure è possibile fare in modo che il test dipenda da entrambe le funzionalità. Avere il tuo test dipende dai dettagli dello stato interno è molto peggio, quindi testare troppe funzionalità insieme.

score 1 · Answer 2

Risposta breve - sì, sì. Se provi remove con qualcosa che coinvolge getById e prova getById con qualcosa che coinvolge remove , allora entrambi potrebbero fallire simultaneamente e non otterrai alcuna indicazione.

La soluzione semplice è semplicemente non usare altre funzioni nel test. Ad esempio, utilizzando le query in testo semplice, poiché si conosce la struttura del DB di test e esattamente ciò che si aspetta. Questo diventerà un incubo di manutenzione se si esegue la migrazione dei database però.

Un altro è di avere un insieme di metodi di base che vengono testati usando test appropriati che non invocano altri metodi e usano solo una configurazione elaborata. È quindi OK utilizzare questi metodi testati in test più complessi di altre funzioni. Di solito queste funzioni "di base" formano anche una classe speciale (e questo è un vantaggio, dal momento che chiunque non conosce il proprio ambiente non conoscerà questa modalità di configurazione e test per alcuni ma non altri metodi di una classe).