Come dovrei testare un metodo che popola un elenco da un DataReader?

Question

Quindi sto lavorando su un codice legacy che grava pesantemente sulle operazioni manuali del database.Sto cercando di mantenere una parvenza di qualità qui, quindi vado TDD il più possibile.

Il codice su cui sto lavorando deve essere popolato, diciamo a List<Foo> da un DataReader che restituisce tutti i campi richiesti per un Foo funzionante.Tuttavia, se voglio verificare che il codice restituisca effettivamente un elemento dell'elenco per riga del database, sto scrivendo un codice di prova simile al seguente:

Expect.Call(reader.Read()).Return(true);
Expect.Call(reader["foo_id"]).Return((long) 1);
// ....
Expect.Call(reader.Read()).Return(true);
Expect.Call(reader["foo_id"]).Return((long) 2);
// ....
Expect.Call(reader.Read()).Return(false);

Il che è piuttosto noioso e anche piuttosto facile da rompere.

Come dovrei affrontare questo problema in modo che il risultato non sia un enorme caos di test fragili?

A proposito, attualmente sto usando Rhino.Mocks per questo, ma posso cambiarlo se il risultato è abbastanza convincente.Basta che l'alternativa non sia TypeMock, perché l'ultima volta che ho controllato il loro EULA era un po' troppo spaventoso per i miei gusti.

Modificare:Attualmente sono anche limitato a C# 2.

Answer 1

Per renderlo meno noioso, dovrai incapsulare/refactoring la mappatura tra DataReader e l'oggetto che conservi nell'elenco.Ci sono pochi passaggi per incapsulare quella logica.Se questa è la strada che vuoi prendere, posso pubblicare il codice per te.Non sono sicuro di quanto sarebbe pratico pubblicare il codice qui su StackOverflow, ma posso fare un tentativo per mantenerlo conciso e pertinente.Altrimenti, sei bloccato nel noioso compito di ripetere ogni aspettativa sulla funzione di accesso all'indice per il lettore.Il processo di incapsulamento eliminerà anche le stringhe e le renderà più riutilizzabili durante i test.

Inoltre, non sono sicuro a questo punto di quanto desideri rendere il codice esistente più testabile.Poiché si tratta di codice legacy che non è stato creato pensando ai test.

Answer 2

Ho pensato di pubblicare del codice e poi mi sono ricordato del corso Nothin But .NET di JP Boodhoo.Lui ha un progetto campione che sta condividendo e che è stato creato durante una delle sue lezioni.Il progetto è ospitato su Codice Google ed è una bella risorsa.Sono sicuro che contenga alcuni suggerimenti utili da utilizzare e ti dia idee su come eseguire il refactoring della mappatura.L'intero progetto è stato realizzato con TDD.

Answer 3

Puoi inserire le istanze Foo in un elenco e confrontare gli oggetti con ciò che leggi:

var arrFoos = new Foos[]{...}; // what you expect
var expectedFoos = new List<Foo>(arrFoos); // make a list from the hardcoded array of expected Foos
var readerResult = ReadEntireList(reader); // read everything from reader and put in List<Foo>
Expect.ContainSameFoos(expectedFoos, readerResult); // compare the two lists

Answer 4

Kokos,

Un paio di cose che non vanno lì.Innanzitutto, farlo in questo modo significa che devo prima costruire i Foo, quindi fornire i loro valori al finto lettore che non fa nulla per ridurre la quantità di codice che sto scrivendo.In secondo luogo, se i valori passano attraverso il lettore, i Foos non saranno i Stesso Foos (uguaglianza di riferimento).Potrebbero esserlo pari, ma anche questo presuppone troppo della classe Foo che non oso toccare a questo punto.

Answer 5

Giusto per chiarire, vuoi essere in grado di testare la tua chiamata in SQL Server che ha restituito alcuni dati o che se avessi dei dati potresti mapparli nuovamente nel modello?

Se vuoi testare la tua chiamata in SQL, hai restituito alcuni dati, controlla la mia risposta trovata Qui

Answer 6

@Correre:Quello che sto testando è la mappatura programmatica dei dati restituiti dal database al modello di dominio senza virgolette.Quindi voglio deridere la connessione al database.Per l'altro tipo di test, opterei per un test di integrazione totale.

@Dale:Immagino che tu abbia azzeccato abbastanza bene lì, e temevo che potesse essere il caso.Se hai indicazioni su articoli o simili in cui qualcuno ha fatto il lavoro sporco e lo ha scomposto in passaggi più facilmente digeribili, lo apprezzerei.Anche gli esempi di codice non farebbero male.Ho un'idea su come affrontare questo problema, ma prima di osare davvero farlo, avrò bisogno di fare altre cose, e se testarlo richiederà noiose prese in giro, allora è quello che farò.