2008-09-24 16 views
5

¿Cuándo se prueba con un In-Memory Database frente a una base de datos de desarrollo?¿En qué casos prueba con una base de datos en memoria en lugar de una base de datos de desarrollo?

Además, como una pregunta lateral relacionada, cuando utiliza una Base de datos de desarrollo, ¿utiliza una Base de datos de desarrollo individual, una Base de datos de desarrollo de integración o ambas?

También ++, para pruebas unitarias, ¿cuándo utiliza una base de datos en memoria sobre burlarse de su repositorio/DAL, etc.?

Respuesta

2

Para mi equipo, está en la memoria en la máquina de desarrollo, y la base de datos real en el servidor de integración continua.

7

En memoria es una excelente opción para su unidad -prueba, cuando los datos son fáciles de sembrar para sus casos de prueba dados y se está probando una operación muy particular. Una base de datos real es mejor para las pruebas de integración , donde los prerrequisitos de datos son más complejos y existe un valor para que los datos base permanezcan después de que se completen las pruebas.

Para nosotros, lo único que permitimos en nuestro conjunto de pruebas "rápidas" de pruebas JUnit son aquellas que no tienen dependencias externas (base de datos, archivos, redes, etc.) para que la suite pueda ejecutarse rápida y eficientemente por ambos desarrolladores y la integración continua en checkin. Si hay una determinada prueba que absolutamente debe ir a la base de datos, entonces una en la memoria es el único camino a seguir.

un par de puntos a tener en cuenta:

  • pensar cuidadosamente si es necesario utilizar una base de datos en absoluto en una prueba unitaria. Es puede ser indicativo de un diseño pobre en que la capa de acceso a datos es acoplada demasiado estrechamente a la lógica comercial que está tratando de probar y no se puede burlar.
  • Si utiliza una base de datos real para pruebas de integración, asegúrese de que las pruebas siempre restablecen los datos a un estado prístino cuando hayan terminado. He visto un montón de tiempo perdido y pruebas de integración fallidas porque alguna otra prueba dañó los datos.

En cuanto a su otra pregunta, realmente depende de su necesidad. Una buena regla empírica es una base de datos de desarrollo por rama de código, ya que pueden ser necesarios cambios de esquema que no sean relevantes para otra rama de código. Solo teniendo es importante una base de datos de desarrollo dedicada; Me sorprende cuántos equipos de desarrollo tienen que compartir una base de datos con el equipo de control de calidad, etc. Es importante poder hacer cambios en un entorno de espacio aislado que no afecte a otros equipos o impedir que otros hagan su trabajo, por lo que si has cumplido con los requisitos que estás haciendo bien.

Cuestiones relacionadas