¿Burlándose contra DB de prueba?

Question

Anteriormente hice esta pregunta ¿Cómo probar la unidad correctamente mi DAL? , una cosa que me queda sin respuesta es si realmente probar mi DAL es tener un DB de prueba, entonces, ¿cuál es el papel de burlarse frente a un DB de prueba?

Para agregar a esto, otra persona sugirió & "; usar transacciones y revertir al final de la prueba unitaria, para que db esté limpio &"; probar db eso es. ¿Qué piensan ustedes de este enfoque de prueba + prueba DB + reversión de transacción (por lo que db no está realmente escrito) para probar DAL?

Para completar, mi DAL está construido con Entity Framework, no hay ningún proceso almacenado en DB. Como EF es tan nuevo, realmente necesito probar DAL para asegurarme de que funcionen correctamente.

Answer 1

Creo que probablemente querrá hacer algunas pruebas de integración para verificar la lógica aplicada por la estructura de su base de datos, por ejemplo, restricciones, disparadores, columnas de autoincremento, etc. Sin embargo, para las pruebas unitarias, simule los componentes del marco que su DAL confía en lo que desea (en sus pruebas unitarias) para probar solo aquellos componentes que ha codificado. Realmente no necesita probar métodos en SqlCommand o SqlConnection (por ejemplo). Debe suponer que los componentes del marco que usa funcionan y crean stubs o simulacros 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 sea necesario realizarlas con la misma frecuencia que las pruebas unitarias y es posible que no tengan que ser tan extensas como la calidad de su código mejora con las pruebas unitarias, pero las pruebas unitarias no son una bala mágica.

Answer 2

No me pareció que la burla fuera 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 dificultaría la prueba.

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

Con respecto al uso de transacciones, ciertamente es posible, siempre que su arquitectura tenga espacio para comenzar una transacción al comienzo de la prueba, y luego hacer todas las llamadas relacionadas con la base de datos de su prueba unitaria dentro de esa transacción. Sin embargo, nunca lo intenté.

Answer 3

Poner pruebas unitarias en transacciones que retroceden suena loco. En lugar de eso, tengo un código que limpia la base de datos de cualquier error (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, ayuda tener los datos aún en la base de datos para inspeccionar cuál es la causa de la falla.

Answer 4

hemos utilizado pruebas unitarias transaccionales y eso evitó los problemas de mapeo de Hibernate varias veces. De lo contrario, ¿qué es una prueba unitaria? ¿Algo trivial como List<Item> getAllItems()? :)

Answer 5

Al usar una base de datos de prueba, abre la posibilidad de que se puedan causar problemas en la base de datos o en la ruta de comunicación (red, etc.) entre el DAL y la base de datos. Burlarse elimina esas posibilidades.

Answer 6

No solo debe considerar el estado de la base de datos, sino también la disponibilidad. Si su base de datos 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

Sin embargo, no solo estás probando tu aplicación. También está probando su configuración y sus procedimientos almacenados y vistas. Estos están documentados en sus pruebas unitarias.

Answer 8

El problema bien podría estar en la pregunta original. Algunos de los ejemplos más populares de MVC usan un atajo al devolver un DbSet como:

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í, esto combina estrechamente la implementación de la persistencia, que creo que es algo malo. Sería mejor devolver List<t> que podría ser fácilmente burlado.