¿Cómo se prueba la persistencia de la unidad?

Question

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

sé que técnicamente esto sería una prueba de integración (no es una prueba de la unidad), pero yo quiero descubrir las mejores estrategias para el siguiente:

1. consultas de prueba.
2. Inserciones de prueba. ¿Cómo sé que la inserción que salió mal si falla? Puedo probarlo insertando y luego consultando, pero ¿cómo puedo saber que la consulta no fue incorrecta?
3. actualizaciones pruebas y elimina - igual que las pruebas inserta

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

---

En cuanto a SQL prueba: Soy consciente de que esto se podría hacer, pero si uso un asignador de O/R como NHibernate, que atribuye algunas verrugas de nomenclatura en los alias utilizados para las consultas de salida, y ya que es algo impredecible. No estoy seguro de poder probar eso.

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

Answer 1

Busque en la unidad DB. Es una biblioteca de Java, pero debe haber un equivalente de 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. Se puede ejecutar contra muchos sistemas de bases de datos, por lo que puede usar su configuración de 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 comprobar que su código está utilizando la base de datos correctamente (lo que probablemente debería hacer), entonces esta es la forma de aislar cada prueba y asegurarse de que la base de datos tiene preparados los datos esperados.

Answer 2

Realiza la prueba unitaria burlándose de la conexión de la base de datos. De esta forma, puede crear escenarios donde las consultas específicas en el flujo de una llamada a método tienen éxito o fallan. Normalmente 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; las especificaciones del SQL son irrelevantes para ese fin.

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

Answer 3

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

Answer 4

El problema que experimenté al probar la unidad de persistencia, especialmente sin un ORM y burlando su base de datos (conexión), es que realmente no sé si tus consultas tienen éxito. Puede ser que sus consultas estén específicamente diseñadas para una versión de base de datos particular y solo tengan éxito con esa versión. Nunca lo sabrá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 ejecutan en la base de datos de destino.

Answer 5

Para NHibernate, yo recomendaría simplemente burlarme de la API de NHibernate para pruebas unitarias: confíe en que la biblioteca hará lo correcto. Si desea asegurarse de que los datos realmente vayan al DB, realice una prueba de integración.

Answer 6

Las pruebas unitarias técnicas de persistencia no son pruebas unitarias, son pruebas de integración.

con C# utilizando MbUnit, sólo tiene que utilizar el SqlRestoreInfo y atributos Rollback

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

     [SetUp] 
     public void Setup() 
     { 

     } 

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

El mismo se puede hacer en NUnit, excpet los nombres de los atributos difieren levemente.

En cuanto a verificar si su consulta fue exitosa, normalmente debe seguirla con una segunda consulta para ver si la base de datos ha sido modificada como esperaba.

Answer 7

He escrito una publicación aquí referente a unit testing the data layer que cubre este problema exacto. Disculpas por el (vergonzoso) complemento, pero el artículo es demasiado largo para publicar aquí.

Espero que eso te ayude, me ha funcionado muy bien durante los últimos 6 meses en 3 proyectos activos.

Saludos,

Rob G

Answer 8

Como Mike Stone said, DbUnit es ideal para obtener la base de datos en un estado conocido antes de ejecutar las pruebas. Cuando terminen sus pruebas, DbUnit puede volver a poner la base de datos en el estado en que se encontraba antes de ejecutar las pruebas.

DbUnit (Java)

DbUnit.NET

Answer 9

por lo general se crea un repositorio y el uso que para salvar mi entidad, a continuación, recuperar una nueva. Entonces afirmo que el recuperado es igual al guardado.

Answer 10

Para proyectos basados ​​en JDBC, se puede usar Acolyte framework: http://acolyte.eu.org. Permite simular el acceso a los datos que desea probar, beneficiándose de la abstracción de JDBC, sin tener que administrar un DB de prueba específico.