Pruebas unitarias con Data Access Layer

¿Cuál es una buena manera de escribir pruebas unitarias con un LINQ to SQL DAL?Pruebas unitarias con Data Access Layer

Actualmente estoy haciendo algunas pruebas de bases de datos y necesito crear métodos auxiliares que accedan a la base de datos, pero no quiero esos métodos en mis repositorios principales.

Así que lo que tengo son dos copias del DAL, una en mi proyecto principal y otra en el proyecto de prueba. ¿Es más fácil administrar estas cosas si creo un proyecto separado para la capa de datos? No estoy seguro de qué manera es una mejor forma de abordar esto.

Si creo un proyecto de capa de datos, ¿movería todos mis repositorios a ese proyecto también? No estoy seguro de cómo configurar correctamente las capas.

Gracias

Fuente

2010-05-05 chobo

Leí el mensaje "Si creo un proyecto de capa de datos, ¿movería todos mis repositorios a ese proyecto también?" pregunta como si ya estuviera usando el patrón de repositorio sugerido en las respuestas a continuación, pero aparentemente también tiene que hacer algún tipo de acceso a la base de datos, en algunas de sus pruebas? Normalmente, esto significa que realmente está probando Linq a SQL, lo que esperaría que los ingenieros de Microsofts ya hubieran hecho.Te aconsejo que evites esos métodos y pruebes tus repositorios con un backend de contexto de memoria, como se describe en el artículo al que Jason Jones se vincula. – AHM

que estoy usando para mi Linq2Sql capa DAL y lo tengo como un proyecto separado. En mi proyecto de dominio tengo una interfaz de repositorio que luego implemento usando un Linq2SqlCarRepository personalizado en mi proyecto DAL, esta clase completa las clases Linq2Sql generadas.

por ejemplo. En proyecto Car.Core

public interface ICarRepository 
{ 
    IQueryable<Car> GetAllCars(); 
    void Add(Car); 
}

entonces tengo una implementación de la interfaz que se clausura el acceso a la clase Linq2Sql generado.

proyecto Car.Data

public class SqlCarRepository : ICarRepository 
{ 
    private CarDataContext _context; 

    public SqlCarRepository() 
    { 
     _context = new CarDataContext(); 
    } 

    #region ICarRepository Members 

    public IQueryable<Car> GetAllCars() 
    { 
     return _context.Cars; 
    }

entonces tengo un proyecto de prueba Car.Data.Test que luego se burla utiliza para burlarse del ICarRepository y las pruebas de distancia. Creo que esto es ligeramente diferente a lo que describes. Pero creo que quieres probar y separar que eres DAL de tu aplicación, por lo que es un periférico que podría cambiarse si así lo deseas.

no tengo todo el completamente ordenados, pero actualmente tengo estos proyectos:

Car.Core   --- All the interfaces and domain objects, DTO's etc 
Car.Core.Tests --- The tests of the core business logic. 
Car.Web   --- Asp.net MVC frontend 
Car.Web.Tests --- Tests for the website 
Car.Data   --- The Linq2Sql stuff lives in here 
Car.Data.Tests --- The tests for the DAL layer

Eso es lo que tengo actualmente pesar de que podría no ser la mejor manera de hacer las cosas ahora.

Recomiendo leer The Onion Architecture y mirar los videos MVC StoreFront para inspirarse; buena suerte.

Fuente

2010-05-05 20:21:36 danswain

Usaría el patrón de repositorio descrito en el artículo de septiembre de 2009 en la revista Visual Studio titulado "Eliminar las dependencias de la base de datos en el desarrollo basado en pruebas". He estado usando este patrón desde que leí el artículo con gran éxito. Este patrón ayudará a desacoplar la capa de datos y a escribir buenas pruebas unitarias.

Esto requerirá que adopte una arquitectura de n niveles y cree una capa de datos separada, pero a la larga vale la pena.

Aquí hay un enlace al artículo en línea. Repository Pattern

Fuente

2010-05-05 20:41:39

Pruebas unitarias con Data Access Layer

Respuesta

Cuestiones relacionadas