burla vs. prueba DB?

Question

Antes he hecho esta pregunta How to correctly unit test my DAL?, una cosa sin respuesta para mí es si realmente a prueba mi DAL es tener una prueba de DB, entonces ¿cuál es el papel de burla frente a una base de datos de pruebas?

Para añadir a esto, otra persona sugirió a las "transacciones de uso y la reversión al final de la prueba de la unidad, por lo que el PP está limpio", db prueba que es. ¿Qué piensan ustedes de este método de prueba + prueba DB + reversión de transacción (entonces, db realmente no está escrito) para probar DAL?

Para ser completa, mi DAL está construido con Entity Framework, no hay procedimiento almacenado en la base de datos. Dado que EF es tan nuevo, realmente necesito probar DAL para asegurarme de que funcionan correctamente.

Answer 1

Creo que probablemente quiera hacer algunas pruebas de integración para verificar la lógica que impone la estructura de su base de datos, por ejemplo restricciones, desencadenantes, columnas de autoincremento, etc. Sin embargo, para las pruebas de unidad, se debe componentes de los que depende su DAL, según lo desee (en las pruebas de su unidad) para probar solo los componentes que ha codificado. Realmente no necesita probar métodos en SqlCommand o SqlConnection (por ejemplo). Debe suponer que los componentes de framework que utiliza funcionan y crean stubs o burlas para ellos que devuelven datos conocidos (buenos, malos, excepciones) a sus métodos para asegurarse de que sus métodos funcionen correctamente. Sin burlarse, usted es responsable de generar los datos en la base de datos y asegurarse de que sean correctos. También deja dependencias abiertas en la red, la base de datos en sí, etc. que pueden hacer que sus pruebas sean frágiles.

Además, las pruebas unitarias no eliminan la necesidad de otros tipos de pruebas. Las pruebas de integración y las pruebas de aceptación siguen siendo válidas y deben realizarse. Probablemente no necesiten hacerlo con la misma frecuencia que las pruebas unitarias y puede que no necesite ser tan extenso como mejora la calidad del código con las pruebas unitarias, pero las pruebas unitarias no son una solución mágica.

Answer 2

Mediante el uso de una base de datos de prueba, que abren la posibilidad de que los problemas pueden ser causados ​​en la propia base de datos oa lo largo de la ruta de comunicación (redes, etc.) entre el DAL y base de datos. Burlarse elimina esas posibilidades.

Answer 3

No encontré la burla muy útil al probar el código de acceso a datos. El propósito de las pruebas unitarias es verificar que el código relacionado con la base de datos funcione y burlarse de la base de datos podría dificultar la prueba.

El burlarse realmente se vuelve útil cuando se prueba el código comercial. Puede simular sus llamadas a la base de datos para devolver datos de prueba y verificar el comportamiento de la lógica comercial en esas circunstancias.

En cuanto al uso de transacciones, es posible, siempre que su arquitectura tenga espacio para iniciar una transacción al comienzo de la prueba y luego realice todas las llamadas relacionadas con la base de datos de su unidad dentro de esa transacción. Nunca lo intenté, sin embargo.

Answer 4

hemos utilizado las pruebas unitarias transaccionales y que impedía Hibernate problemas para asignar varias veces. De lo contrario, ¿qué hay para probar la unidad? Algo trivial como List<Item> getAllItems()? :)

Answer 5

Poner pruebas unitarias en las transacciones que retroceden suena a hacky. En lugar de eso, tengo un código que limpia la base de datos de cualquier crud (es decir, cualquier cosa que no sea estática/datos de referencia) antes de que se ejecuten las pruebas (es decir, en el constructor de mi clase de prueba). Cuando sus pruebas fallan, es útil tener los datos aún en la base de datos para inspeccionar cuál es la causa de la falla.

Answer 6

No es solo el estado de la base de datos que debe tener en cuenta, también es la disponibilidad. Si su DB está fuera de línea, ¿por qué deberían fallar todas sus pruebas DAL?

Lo que necesita probar es que su DAL emite los comandos correctos para crear/recuperar/actualizar/eliminar. No necesita ejecutar SQL para esto, solo puede usar un marco de persistencia de objetos y verificar que le dé las instrucciones correctas.

Answer 7

El problema podría estar en la pregunta original. Algunos de los ejemplos más populares de MVC utiliza un acceso directo al devolver un DbSet tales como: esta fuertemente a las parejas la aplicación

public class MusicStoreEntities : DbContext 
    { 
     public DbSet<Album> Albums { get; set; } 
     public DbSet<Genre> Genres { get; set; } 
     public DbSet<Artist> Artists { get; set; } 
     public DbSet<Cart> Carts { get; set; } 
     public DbSet<Order> Orders { get; set; } 
     public DbSet<OrderDetail> OrderDetails { get; set; } 
    } 

Para mí de la persistencia que creo que es una mala cosa. Sería mejor devolver List<t> que podría ser fácilmente burlado.

Answer 8

No solo está probando su aplicación. También está probando su configuración y sus procedimientos almacenados y vistas. Estos están documentados en las pruebas de su unidad.