pruebas - Mejores prácticas para probar bases de datos con PHPUnit

phpunit laravel

Question

El propio manual de PHPUnit tiene algunas secciones aún no escritas tituladas "Operaciones" y "Mejores prácticas de prueba de bases de datos".

¿Cuáles son las mejores prácticas para probar una base de datos con PHPUnit , particularmente en MySQL ?

Answer 1

Algunos pensamientos desordenados:

Es bueno tener dispositivos (con o sin estructura de db), cargados en db en startUp () de cada prueba. Puede venir ie. desde archivos JSON o XML, uno para cada tabla. Si lo combina con funciones como getNthFixture ($ sTable, $ nIndex) o countFixtures ($ sTable), puede probar sus consultas fácilmente. Aún más, puede usar [LINQ] [1] para obtener los resultados esperados de un conjunto de aparatos con poca o ninguna diferencia entre la base de datos y la consulta de dispositivos. Me resulta bastante fácil adaptarse en la etapa temprana de creación de prototipos / desarrollo, cuando la estructura db está cambiando muy a menudo. Agregar una aserción para comparar directamente el resultado de la consulta LINQ con el resultado de la consulta db hace que la creación de pruebas sea un verdadero placer;)

Otros consejos: db debe reinicializarse antes de cada método de prueba, no antes del caso de prueba. Idealmente, debería dejar caer la base y reconstruirla a partir de un conjunto completo de accesorios.

Y, si puede, intente realizar pruebas que funcionen con diferentes bases de datos (algunas cosas, por supuesto, no son portátiles, pero la mayoría sí lo son). Utilice al menos sqlite a un lado de mysql / postgres / other_big_rdbm.

Si está probando framework u otro sistema complejo, probablemente debería simular un acceso único a la base de datos. Si algunas cosas codificadas están enterradas profundamente en orcos no tan flexibles, puede ser dolor en el cuello, digamos, por ejemplo.

Una buena idea es registrar todas las consultas que no pasaron la prueba y / o mostrarlas en los mensajes de error. También para mensajes de error db. Si está probando grandes bases de datos cuando el rendimiento es una preocupación, intente registrar consultas lentas al mismo tiempo.

Más mágico y quizás un poco más difícil, es automatizar las pruebas para ver si todas las columnas utilizadas en donde / having / joins están indexadas. Es tal vez algo que debería pertenecer a Jointed Php / Database Code Sniffer (tm) en lugar de pruebas unitarias, y no es muy simple de implementar, pero una vez que se usa, asegura en gran medida la calidad del código.

Otro buen consejo, que va desde la triste experiencia personal: siempre agregue pruebas para conjuntos de caracteres muy buenos, especialmente si trabaja con muchos idiomas diferentes. El mundo ISO-8859-1 es muy pequeño;)

[1]: http://phplinq.codeplex.com/ LINQ

Answer 2

Cuando hago pruebas de bases de datos con PHPUnit, cargo mi volcado de MySQL al inicio de la primera suite que contiene toda la información que asumo que es verdadera en todas las pruebas. Cuando se inicia cada prueba, uso un método setupDatabase. Este método elimina todas las filas de las tablas que sé que han cambiado y, a continuación, carga un conjunto de datos XML plano que contiene los datos que necesito para mantener el valor verdadero. Una vez hecho esto, ejecuto cualquier código que estoy probando. Finalmente, utilizo una colección de métodos simples para seleccionar filas de la base de datos para afirmar que los cambios que hice se realizaron correctamente.

No diría que esta es una buena práctica, pero me ha funcionado bastante bien. Los únicos problemas con los que me he encontrado son tener que buscar y reemplazar los conjuntos de datos XML cada vez que el esquema cambia y las pruebas se ejecutan lentamente como resultado de la eliminación y la inserción.

Zend Framework tiene una biblioteca interesante para PHPUnit que permite que las pruebas comparen una tabla de base de datos con un conjunto de datos XML plano, pero aún no he tenido la oportunidad de usarla.