¿Cómo prueban las personas el código que usa Linq to SQL?

StackOverflow https://stackoverflow.com/questions/52657

  •  09-06-2019
  •  | 
  •  

Pregunta

¿Cómo prueban las personas el código que utiliza Linq to SQL?

¿Fue útil?

Solución

Actualizar:

Fredrik ha publicado una solución de ejemplo sobre cómo realizar pruebas unitarias de aplicaciones linq2sql en su blog.Puedes descargarlo en:

http://web.archive.org/web/20120415022448/http://iridescent.no/post/DataContext-Repository-Pattern-Example-Code.aspx

No sólo creo que es genial que haya publicado una solución de ejemplo, sino que también logró extraer interfaces para todas las clases, lo que hace que el diseño esté más desacoplado.

Mi antigua publicación:

*Encontré estos blogs que creo que son un buen comienzo para crear el contenedor DataContext:Enlace1 Enlace2

Cubren casi el mismo tema excepto que el primero también implementa medios para extraer interfaces para las tablas.El segundo es más extenso, así que lo incluí también.*

Otros consejos

3 años de retraso, pero así es como lo hago:

https://github.com/lukesampson/LinqToSQL-test-extensions/

No es necesario escribir un contenedor ni hacer muchas tareas de plomería, simplemente coloque la plantilla T4 al lado de su .dbml y obtendrá:

  1. Una interfaz para su contexto de datos, p.IExampleDataContext
  2. Una simulación en memoria para su contexto de datos, p.MemoriaEjemploContexto de datos

Ambos utilizarán automáticamente las asignaciones que ya has configurado en tu DBML.

Entonces puedes hacer cosas como

public class ProductRepo {
    IExampleDataContext DB { get; set };
    public ProductRepo(IExampleDataContext db) {
        DB = db;
    }

    public List<Product> GetProducts() {
        return DB.Products.ToList();
    }
}

y puedes llamar a eso con cualquiera

new ProductRepo(new MemoryExampleDataContext()).GetProducts(); // for testing

o

new ProductRepo(new ExampleDataContext()).GetProducts(); // use the real DB

Envuelva el DataContext, luego simule el contenedor.Es la forma más rápida de hacerlo, aunque requiere codificación para las pruebas, lo que algunas personas piensan que huele mal.Pero a veces, cuando tienes dependencias de las que no se puede burlar (fácilmente), es la única manera.

Linq facilita mucho las pruebas.Las consultas de Linq funcionan tan bien en Listas como en Linq-to-sql.Puede cambiar Linq a SQL para objetos de lista y probar de esa manera.

Mattwar en El registro web descarriado Tenía un gran artículo sobre cómo simular un contexto de datos Linq2Sql extensible.Échale un vistazo -- MOCKS NIX: UN LINQ EXTENSIBLE AL CONTEXTO DE DATOS SQL

Normalmente, no es necesario probar la parte del código que usa LINQ to SQL, pero si realmente lo desea, puede usar los mismos conjuntos de datos que está consultando en el servidor y convertirlos en objetos en memoria y ejecute las consultas LINQ contra eso (lo que usaría los métodos enumerables en lugar de consultables).

Otra opción es utilizar el de Matt Warren. versión simulada del DataContext.

También puede obtener las declaraciones SQL que utiliza LINQ to SQL obteniéndolas a través del depurador (desde el objeto IQueryable), verificarlas manualmente y luego incluirlas en las pruebas automatizadas.

LINQ to SQL es realmente bueno para realizar pruebas unitarias, ya que tiene la capacidad de crear bases de datos sobre la marcha a partir de lo que está definido en su DBML.

Es realmente agradable probar una capa ORM creando la base de datos a través del DataContext y dejándola vacía para empezar.

Lo cubro en mi blog aquí: http://web.archive.org/web/20090526231317/http://www.aaron-powell.com/blog/may-2008/unit-testing-linq-to-sql.aspx

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top