¿Cómo realizo una prueba unitaria de persistencia?

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

  •  08-06-2019
  •  | 
  •  

Pregunta

Como novato en la práctica del desarrollo basado en pruebas, a menudo termino en un dilema sobre cómo realizar pruebas unitarias de persistencia en una base de datos.

Sé que técnicamente esto sería una prueba de integración (no una prueba unitaria), pero quiero descubrir las mejores estrategias para lo siguiente:

  1. Consultas de prueba.
  2. Insertos de prueba.¿Cómo sé que el inserto que salió mal si falla?Puedo probarlo insertando y luego consultando, pero ¿cómo puedo saber que la consulta no fue incorrecta?
  3. Probar actualizaciones y eliminaciones, igual que probar inserciones

¿Cuáles son las mejores prácticas para hacer esto?

Respecto a las pruebas de SQL:Soy consciente de que esto se podría hacer, pero si uso un mapeador O/R como NHibernate, adjunta algunos errores de nomenclatura en los alias utilizados para las consultas de salida, y como eso es algo impredecible, no estoy seguro de poder realizar pruebas. eso.

¿Debería simplemente abandonar todo y simplemente confiar en NHibernate?No estoy seguro de que sea prudente.

¿Fue útil?

Solución

Mire en la unidad DB.Es una biblioteca Java, pero debe haber un equivalente en C#.Le permite preparar la base de datos con un conjunto de datos para que sepa qué hay en la base de datos, luego puede interactuar con DB Unit para ver qué hay en la base de datos.Puede ejecutarse en muchos sistemas de bases de datos, por lo que puede usar la configuración de su base de datos real o usar algo más, como HSQL en Java (una implementación de base de datos Java con una opción en memoria).

Si desea probar que su código utiliza la base de datos correctamente (lo que probablemente debería hacer), esta es la forma de aislar cada prueba y asegurarse de que la base de datos tenga preparados los datos esperados.

Otros consejos

Como mike piedra dijo, DbUnit es excelente para llevar la base de datos a un estado conocido antes de ejecutar las pruebas.Cuando finalicen las pruebas, DbUnit puede devolver la base de datos al estado en el que se encontraba antes de ejecutar las pruebas.

Unidad DB (Java)

DbUnit.NET

Realiza las pruebas unitarias burlándose de la conexión de la base de datos.De esta manera, puede crear escenarios en los que consultas específicas en el flujo de una llamada a un método tienen éxito o fallan.Por lo general, construyo mis expectativas simuladas para que se ignore el texto de la consulta real, porque realmente quiero probar la tolerancia a fallas del método y cómo se maneja a sí mismo; los detalles del SQL son irrelevantes para ese fin.

Obviamente, esto significa que su prueba en realidad no verificará que el método obras, porque el SQL puede estar equivocado.Aquí es donde entran en juego las pruebas de integración.Para eso, espero que alguien más tenga una respuesta más completa, ya que yo apenas estoy empezando a familiarizarme con ellas.

He escrito una publicación aquí sobre prueba unitaria de la capa de datos que cubre este problema exacto.Disculpas por el (vergonzoso) complemento, pero el artículo es demasiado largo para publicarlo aquí.

Espero que te ayude; a mí me ha funcionado muy bien durante los últimos 6 meses en 3 proyectos activos.

Saludos,

Rob G.

El problema que experimenté cuando probé la persistencia de la unidad, especialmente sin un ORM y, por lo tanto, burlándome de su base de datos (conexión), es que realmente no sabe si sus consultas tienen éxito.Podría ser que sus consultas estén diseñadas específicamente para una versión de base de datos en particular y solo tengan éxito con esa versión.Nunca lo descubrirás si te burlas de tu base de datos.Entonces, en mi opinión, la persistencia de las pruebas unitarias solo tiene un uso limitado.Siempre debe agregar pruebas que se ejecuten en la base de datos de destino.

Para NHibernate, definitivamente recomendaría simplemente burlarse del NHibernate API para pruebas unitarias: confíe en que la biblioteca hará lo correcto.Si desea asegurarse de que los datos realmente lleguen a la base de datos, realice una prueba de integración.

Para proyectos basados ​​en JDBC, se puede utilizar mi marco Acolyte: http://acolyte.eu.org .Permite simular el acceso a los datos que desea probar, beneficiándose de la abstracción JDBC, sin tener que administrar una base de datos de prueba específica.

También me burlaría de la base de datos y verificaría que las consultas sean las que esperaba.Existe el riesgo de que la prueba revise el sql incorrecto, pero esto se detectaría en las pruebas de integración.

Técnicamente, las pruebas unitarias de persistencia no son pruebas unitarias, son pruebas de integración.

Con C# usando mbUnit, simplemente usa los atributos SqlRestoreInfo y RollBack

    [TestFixture]
    [SqlRestoreInfo(<connectionsting>, <name>,<backupLocation>]
    public class Tests
    {

        [SetUp]
        public void Setup()
        {

        }

        [Test]
        [RollBack]
        public void TEST()
        {
           //test insert. 
        }
    }

Se puede hacer lo mismo en NUnit, excepto que los nombres de los atributos difieren ligeramente.

En cuanto a comprobar si su consulta fue exitosa, normalmente deberá seguirla con una segunda consulta para ver si la base de datos ha cambiado como esperaba.

Por lo general, creo un repositorio y lo uso para guardar mi entidad y luego recupero una nueva.Luego afirmo que lo recuperado es igual a lo salvado.

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