¿Cómo debo probar un método que completa una lista desde un DataReader?

Question

Así que estoy trabajando en un código heredado que requiere muchas operaciones manuales de bases de datos.Estoy tratando de mantener algo parecido a la calidad aquí, así que voy a usar TDD tanto como sea posible.

El código en el que estoy trabajando necesita completarse, digamos un List<Foo> de un DataReader que devuelve todos los campos necesarios para un Foo en funcionamiento.Sin embargo, si quiero verificar que el código de hecho devuelve un elemento de la lista por fila de la base de datos, estoy escribiendo un código de prueba similar a este:

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);

Lo cual es bastante tedioso y también bastante fácil de romper.

¿Cómo debería abordar este problema para que el resultado no sea un gran lío de pruebas frágiles?

Por cierto, actualmente estoy usando Rhino.Mocks para esto, pero puedo cambiarlo si el resultado es lo suficientemente convincente.Siempre y cuando la alternativa no sea TypeMock, porque su EULA daba un poco de miedo para mi gusto la última vez que lo verifiqué.

Editar:Actualmente también estoy limitado a C# 2.

Answer 1

Para que esto sea menos tedioso, necesitará encapsular/refactorizar el mapeo entre el DataReader y el Objeto que tiene en la lista.Hay bastantes pasos para resumir esa lógica.Si ese es el camino que desea tomar, puedo publicarle el código.Simplemente no estoy seguro de qué tan práctico sería publicar el código aquí en StackOverflow, pero puedo intentarlo para mantenerlo conciso y directo.De lo contrario, se verá atrapado en la tediosa tarea de repetir cada expectativa en el descriptor de acceso al índice para el lector.El proceso de encapsulación también eliminará las cadenas y las hará más reutilizables a través de sus pruebas.

Además, no estoy seguro en este momento de cuánto desea que el código existente sea más comprobable.Dado que este es un código heredado que no se creó teniendo en cuenta las pruebas.

Answer 2

Pensé en publicar algo de código y luego me acordé del curso Nothin But .NET de JP Boodhoo.El tiene un proyecto de muestra que está compartiendo y que fue creado durante una de sus clases.El proyecto está alojado en Código de Google y es un buen recurso.Estoy seguro de que tiene algunos buenos consejos que puede utilizar y le brinda ideas sobre cómo refactorizar el mapeo.Todo el proyecto fue construido con TDD.

Answer 3

Puedes poner las instancias de Foo en una lista y comparar los objetos con lo que lees:

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,

Hay un par de cosas mal ahí.Primero, hacerlo de esa manera significa que primero tengo que construir los Foos y luego alimentar con sus valores al lector simulado, lo que no hace nada para reducir la cantidad de código que estoy escribiendo.En segundo lugar, si los valores pasan por el lector, los Foos no serán los mismo Foos (igualdad de referencia).Puede ser que sean igual, pero incluso eso supone demasiado de la clase Foo que no me atrevo a tocar en este momento.

Answer 5

Solo para aclarar, ¿desea poder probar que su llamada en SQL Server devolvió algunos datos, o que si tuviera algunos datos pudiera asignarlos nuevamente al modelo?

Si desea probar su llamada en SQL, devolvió algunos datos, consulte mi respuesta encontrada aquí

Answer 6

@Toran:Lo que estoy probando es el mapeo programático de los datos devueltos por la base de datos al modelo de dominio entre comillas.Por eso quiero simular la conexión de la base de datos.Para el otro tipo de prueba, optaría por pruebas de integración total.

@Valle:Supongo que lo has logrado bastante bien y temí que ese pudiera ser el caso.Si tiene sugerencias sobre algún artículo o algo similar en el que alguien haya hecho el trabajo sucio y lo haya descompuesto en pasos más fáciles de digerir, se lo agradecería.Las muestras de código tampoco estarían de más.Tengo una idea de cómo abordar ese problema, pero antes de atreverme a hacerlo, tendré que hacer otras cosas, y si probar eso requerirá burlas tediosas, entonces eso es lo que haré.