c# - para - programacion android pdf 2018

Formas de prueba de la unidad de capa de acceso a datos

Question

Intento buscar una forma efectiva en la prueba unitaria de mi capa de acceso a datos en C #. Soy un desarrollador principal de Java y solo he usado C # durante aproximadamente 6 meses, en el pasado he usado una biblioteca llamada DBUnit para probar contra una base de datos de estado conocido. No he podido encontrar una biblioteca activa similar que pueda usarse, el más cercano parece ser nDBUnit pero no ha estado activo por un tiempo.

Parece que hay muchos métodos conflictivos sobre cómo y por qué en C #. Idealmente, quiero probar la capa de acceso a datos mediante simulacros sin la necesidad de conectarse a una base de datos y luego realizar una prueba unitaria del procedimiento de almacenamiento en un conjunto separado de pruebas.

En el sistema en el que estoy trabajando, la capa de acceso a datos es utilizar ADO.net (sin el uso de Entity Framework) para llamar a los procedimientos de almacenamiento en un servidor SQL.

A continuación se muestra un código de ejemplo de lo que tengo que trabajar; para ir por el camino de burla, tendría que ser capaz de burlarse de SqlCommand (usando IDbCommand) y / o burlarse de SqlConnection.

¿Entonces mi pregunta es cuál parece ser la mejor manera (si existe tal cosa) de hacer esto? Hasta ahora, la única forma sería hacer que el objeto Proxy se pase al constructor para que pueda devolver los objetos Sql * simulados para la prueba.

No he tenido la oportunidad de ver todas las bibliotecas simuladas de C # disponibles todavía.

public class CustomerRepository : ICustomerRepository
{
   private string connectionString;

   public CustomerRepository (string connectionString)
   {
     this.connectionString = connectionString;
   }

   public int Create(Customer customer)
   {

     SqlParameter paramOutId = new SqlParameter("@out_id", SqlDbType.Int);
     paramOutId.Direction = ParameterDirection.Output;
     List<SqlParameter> sqlParams = new List<SqlParameter>()
     {
       paramOutId,
       new SqlParameter("@name", customer.Name)
     }

     SqlConnection connection = GetConnection();
     try
     {
       SqlCommand command = new SqlCommand("store_proc_name", connection);

       command.CommandType = CommandType.StoredProcedure;

       command.Parameters.AddRange(sqlParams.ToArray());

       int results = command.ExecuteNonQuery();

       return (int) paramOutId.Value;
     }
     finally
     {
       CloseConnection(connection);
     }

   }

}

Answer 1

El trabajo de esta capa es conectar el código a la base de datos. Tiene que encapsular el conocimiento sobre la conexión y la sintaxis de la base de datos. Generalmente asigna el idioma del dominio al idioma de la base de datos. Veo esta parte de las pruebas unitarias como prueba de integración, y como tal, pruebo que el esquema de la base de datos es equivalente a la base de datos real o de prueba. Más sobre el tema here .

Answer 2

Es lamentable que no pueda encontrar una herramienta que ponga su base de datos en un estado conocido y le permita ejecutar su CustomerRepository contra la base de datos para probar el CustomerRepository. Sin embargo, la respuesta es no comenzar a utilizar simulacros para simular todas las llamadas ADO. Al hacer eso, terminas creando una prueba de unidad que realmente no prueba ninguna lógica: solo prueba que el código está escrito de la manera que piensas que debería escribirse.

Digamos que termino escribiendo un SQL INSERT como mi comando para crear el cliente en la base de datos SQL. Ahora digamos que estamos realizando un cambio para que la tabla de clientes tenga diferentes campos (que rompe nuestro comando INSERTAR) y que ahora deberíamos usar un procedimiento almacenado para crear el cliente. La prueba con simulacros aún pasaría, aunque la implementación que está probando ahora está rota. Además, si arregla la implementación para utilizar procedimientos almacenados, las pruebas de unidad ahora fallarían. ¿Cuál es el punto de una prueba de unidad si continúa pasando cuando debería fallar pero luego fallaría cuando arreglara el sistema?

Vea esta pregunta para algunas posibles alternativas. Parece que la respuesta marcada es en realidad simplemente terminar usando DBUnit en C # usando IKVM.

Por lo tanto, podría haber vías alternativas para continuar explorando, pero burlarse de las llamadas ADO solo llevará a pruebas frágiles que no prueban nada importante.

Answer 3

Para probar DataAccess Layer necesitará una estructura más compleja.

DataAccess Layer llamará las referencias de los objetos del Repositorio. El objeto Repo invocará referencias de Entity Framework DbSets a través del patrón de diseño UnitOfWork.

Capa de acceso a datos (TOP)
|
UnitOfWork
|
Clases de patrones de repositorio
|
Contexto EF
|
Base de datos real

Después de configurar la estructura, simulará las clases del repositorio. Por ejemplo, los elementos se insertarán en la base de datos en su lugar irán al objeto simulado. Más tarde, usted hará valer contra su objeto simulado para ver el elemento insertado o no.

Por favor, eche un vistazo a Implementar el Repositorio y la Unidad de Patrones de Trabajo