¿Por qué debería evitar el uso de DbUnit para probar MySQL?

Question

Recientemente me he involucrado con algunos TDD usando PHPUnit. Tengo que probar una aplicación basada en una base de datos y leer acerca de la extensión DbUnit, que estaba planeando investigar e implementar durante las próximas semanas.

Sin embargo, me he encontrado con este presentation por el hombre mismo - Sebastian Bergmann - Tiene una diapositiva titulada 'Evita las pruebas contra MySQL si puedes', lo que ha arrojado algunas dudas sobre mi escapada.

¿Alguien puede explicar las razones por las que no debería probar contra MySQL?

Gracias

Answer 1

dos razones:

• es lento (y las pruebas de unidad tiene que ser rápido)
• añade punto de falla adicional que está fuera de su control (no prueba muy fallan cuando la conexión falla DB?)

en cambio, como autor sugiere que debe probar su DAL con base de datos en memoria, como SQLit mi. Esto elimina los problemas mencionados anteriormente.

Sin embargo, este enfoque también tiene sus inconvenientes: es posible que tenga problemas para trasladar SQL de un dialecto de base de datos a SQLite. Esto, naturalmente, significa que no podrá probar partes específicas de MySQL de su DAL. Como siempre, es una espada de doble filo: obtienes velocidad de prueba unitaria y aislamiento, pero pierdes credibilidad (si podemos llamarlo así): si pasó SQLite, ¿puedes estar 100% seguro de que funciona en MySQL?

Puede que no sea una mala idea dejar el núcleo de sus pruebas DAL/DAO en la fase de prueba de integración, donde los probará contra el motor DB real que utiliza y dejará cosas pequeñas para las pruebas unitarias; por ejemplo, mapeos (si usa ORM).

Editar: la rápida es de ninguna manera requisito estricto - es sólo un buen consejo general. Al hacer TDD, los desarrolladores ejecutarán pruebas unitarias mucho (piense de esta manera; cada compromiso con el repo local/cada cambio de código importante requerirá una verificación de la integridad de la base del código ejecutando pruebas unitarias); quizás no todos, pero seguramente algunos. Desea que este proceso sea rápido.

Ahora, teniendo pruebas lentas por lo general termina así:

• "Hombre, esto las cosas se ejecuta tan lento ..."
• "Tal vez pueda ejecutar sólo algunos de ellos ... voy a correr resto más tarde"
• en este punto sabemos nunca llega tarde
• 'Hey, mi última confirmación no romper nada y no corre ningún pruebas en absoluto!'
• "¿Por qué iba a ejecutarlos después de todo?"

pruebas por escrito que no se están ejecutando, casi mata el propósito de escribir ellos.

_{Esto le sucedió a un amigo que trabaja conmigo; su equipo tenía un conjunto de pruebas corriendo +/- 20 minutos (pruebas DAL mal hechas, contenedor IoC involucrado en pruebas), los desarrolladores comenzaron a ejecutar algunas pruebas, y muy pronto los correos electrónicos "interruptores de compilación actuales" se convirtieron en algo cotidiano. Tenían suite bastante grande, pero la prueba de ruptura fue no tan malo.}

En general, su enfoque parece correcto - No movería las pruebas a SQLite. Como sugerí, haga que la capa de la base de datos se pruebe con el conjunto de pruebas de integración (de modo que se pueda ejecutar por separado que el conjunto de pruebas de unidades normales).

Answer 2

Uso DbUnit para probar mis modelos (hablando de MVC, incluidos los modelos ORM), porque están estrechamente relacionados con la base de datos. Para todo lo demás (principalmente controladores) utilizo objetos simulados.

La idea básica de las pruebas unitarias es probar solo una unidad de código de aplicación (que es una clase) a la vez, por lo que es mejor evitar usar DB a menos que el código trabaje directamente con él.

Y, por supuesto, el rendimiento es importante. Por ejemplo, tengo ~ 500 de prueba para los modelos, casi todos usan DB y accesorios. Se necesitan entre 30 y 40 segundos para ejecutar todas estas pruebas en una computadora bastante rápida. La generación de informes de cobertura de código lleva alrededor de un minuto.

Answer 3

Estoy totalmente en desacuerdo con el título de la diapositiva 33 escrita por Sebastian Bergmann.

(Debido a que el mensaje de la diapositiva podría ser fácilmente malinterpretado, soy seguro de que en su conferencia explicó el significado real)

Como se dijo en su introducción depuración chupa pero las pruebas rocas.

Si el entorno real usa mySQL, debe probarlo contra mySQL. De lo contrario, se encontrará depurando cuáles son las diferencias entre SQLite y mySQL.

Creo que su dirección va dirigida a desarrolladores en lugar de probadores de unidades, y en ese sentido también sugeriría a los desarrolladores que hagan el esfuerzo necesario para mantener la base de datos de código neutral. Mejorará la calidad del ciclo de vida general del proyecto, no solo los probadores de unidades. Protegerá incluso contra las mejoras de características de mySQL. (Hubo muchos problemas en el pasado).

Pero al probar una sola pieza de código que usa SQL, no importa qué otras pruebas ya haya realizado debe probarlo con.

Mi práctica es crear una capa abstracta de conexión de base de datos y tener pruebas para reaccionar con esa capa. Posteriormente estoy creando diferentes clases concretas para cada servidor de db que quiero probar.

Con ese entorno dado, podemos probar la frecuencia contra SQLite, pero las pruebas reales se ejecutarán al menos una vez al día.