Pregunta

¿Alguien tiene algunos buenos consejos para escribir código de prueba para el desarrollo de bases de datos donde existe una gran dependencia del estado?

Específicamente, quiero escribir pruebas para código que recupere registros de la base de datos, pero las respuestas dependerán de los datos de la base de datos (que pueden cambiar con el tiempo).

¿La gente suele crear un sistema de desarrollo separado con una base de datos 'congelada' para que cualquier función determinada siempre devuelva exactamente el mismo conjunto de resultados?

Estoy bastante seguro de que este no es un tema nuevo, por lo que me interesaría mucho aprender de la experiencia de otras personas.

¿Existen buenos artículos que analicen este tema del desarrollo basado en web en general?

Normalmente escribo código PHP, pero esperaría que todos estos problemas sean en gran medida independientes del lenguaje y el marco.

¿Fue útil?

Solución

Debería buscar en DBUnit o intentar encontrar un equivalente de PHP (debe haber uno disponible).Puede usarlo para preparar la base de datos con un conjunto específico de datos que represente los datos de su prueba y, por lo tanto, cada prueba ya no dependerá de la base de datos ni de algún estado existente.De esta manera, cada prueba es independiente y no se interrumpirá durante el uso posterior de la base de datos.

Actualizar:Una búsqueda rápida en Google mostró un Extensión de la unidad DB para PHPUnidad.

Otros consejos

Si lo que más le preocupa son las pruebas de la capa de datos, es posible que desee consultar este libro: Patrones de prueba xUnit:Código de prueba de refactorización.Yo siempre tuve dudas al respecto, pero este libro hace un gran trabajo para ayudar a enumerar inquietudes como el rendimiento, la reproducibilidad, etc.

Supongo que depende de qué base de datos estés usando, pero Red Gate (www.red-gate.com) crea una herramienta llamada SQL Data Generator.Esto se puede configurar para llenar su base de datos con datos de prueba de apariencia sensata.También puede decirle que use siempre la misma semilla en su generador de números aleatorios para que sus datos "aleatorios" sean los mismos siempre.

Luego puede escribir sus pruebas unitarias para utilizar estos datos confiables y repetibles.

En cuanto a probar el lado web, actualmente estoy investigando Selenium (selenium.openqa.org).Este parece ser un conjunto de pruebas compatible con varios navegadores que le ayudará a probar la funcionalidad.Sin embargo, como ocurre con todas estas herramientas de prueba de sitios web, no existe una forma real de probar qué tan bien funcionan estas cosas. mirar en todos los navegadores sin que un ojo humano los vea!

Usamos una base de datos en memoria (hsql: http://hsqldb.org/).Hibernar (http://www.hibernate.org/) nos facilita apuntar nuestras pruebas unitarias a la base de datos de prueba, con la ventaja adicional de que se ejecutan tan rápido como un rayo.

Tengo exactamente el mismo problema con mi trabajo y encuentro que la mejor idea es tener un script PHP para recrear la base de datos y luego un script separado donde le arrojo datos locos para ver si se rompe.

Nunca he usado ninguna prueba unitaria o algo así, así que no puedo decir si funciona o no, lo siento.

Si puede configurar la base de datos con una cantidad conocida antes de ejecutar las pruebas y eliminarla al final, entonces sabrá con qué datos está trabajando.

Luego, puede usar algo como Selenium para probar fácilmente desde su interfaz de usuario (suponiendo que esté basada en la web, pero existen muchas herramientas de prueba de interfaz de usuario para otros tipos de interfaz de usuario) y detectar la presencia de ciertos registros extraídos de la base de datos.

Definitivamente vale la pena configurar una versión de prueba de la base de datos o hacer que los scripts de prueba llenen la base de datos con datos conocidos como parte de las pruebas.

Tu podrías intentar http://selenium.openqa.org/ Es más para pruebas de GUI que para una aplicación de prueba de capa de datos, pero registra sus acciones que luego se pueden reproducir para automatizar pruebas en diferentes plataformas.

Esta es mi estrategia (uso JUnit, pero estoy seguro de que hay una manera de hacer el equivalente en PHP):

Tengo un método que se ejecuta antes de todas las pruebas unitarias para una clase DAO específica.Pone la base de datos de desarrollo en un estado conocido (agrega todos los datos de prueba, etc.).Mientras realizo pruebas, hago un seguimiento de los datos agregados al estado conocido.Estos datos se limpian al final de cada prueba.Después de que se hayan ejecutado todas las pruebas de la clase, otro método elimina todos los datos de prueba en la base de datos de desarrollo, dejándola en el estado en el que se encontraba antes de ejecutar las pruebas.Es un poco de trabajo hacer todo esto, pero normalmente escribo los métodos en una clase DBTestCommon donde todas mis clases de prueba DAO pueden acceder a ellos.

Propondría utilizar tres bases de datos.Una base de datos de producción, una base de datos de desarrollo (con algunos datos significativos para cada desarrollador) y una base de datos de prueba (con tablas vacías y tal vez algunas filas que siempre son necesarias).

Una forma de probar el código de la base de datos es:

  1. Inserte algunas filas (usando SQL) para inicializar el estado
  2. Ejecute la función que desea probar
  3. Compare los resultados esperados con los reales.Aquí podría utilizar su marco de prueba unitario normal.
  4. Limpiar las filas que se cambiaron (para que la siguiente ejecución no vea la ejecución anterior)

La limpieza podría realizarse de forma estándar (por supuesto, sólo en la base de datos de prueba) con DELETE * FROM table.

En general, estoy de acuerdo con Peter, pero para crear y eliminar datos de prueba no usaría SQL directamente.Prefiero usar alguna API CRUD que se usa en el producto para crear datos lo más similares posible a la producción...

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