Pruebas unitarias en aplicaciones web que usan bases de datos

Question

Estoy creando una aplicación web que usa la base de datos para usuarios, seguridad/roles y para almacenar contenido.

Me parece un poco desalentador comenzar en el camino de las pruebas unitarias porque tengo que asegurarme de que mi base de datos se haya inicializado correctamente para que se ejecuten mis pruebas.

¿Cuáles son las prácticas comunes para ayudar en este sentido?

es decir, mientras que el desarrollo/pruebas, podría eliminar un usuario, pero para mi prueba a suceder que el usuario tiene que estar en la base de datos, junto con sus perfiles, configuraciones de seguridad, etc.

sé que puedo crear una script de configuración, algo que Recreat los databas etc.

yo no quiero terminar gastando todo mi tiempo mantener mis pruebas y la garantía de mi base de datos está en sych

O es que el costo de las pruebas unitarias/TDD?

Answer 1

No es una prueba unitaria si está probando más de una unidad.

Por lo general, tendrá un componente (su página o la capa empresarial) hablando con un objeto de capa de datos que es responsable de conectar y consultar realmente la base de datos. Mi recomendación es desarrollar una prueba unitaria para el primer componente, utilizando la inyección de dependencia para pasar una versión del modelo del DataLayer (que actúa sobre datos codificados, o una lista que se pasa, etc.). De esta manera está probando su código de nivel superior en el aislamiento de los otros componentes.

Luego puede desarrollar otras pruebas unitarias (y pruebas de integración) para la capa de datos para asegurarse de que está manejando su trabajo (escribiendo en la base de datos) correctamente.

Answer 2

Michael Feathers argumenta que las pruebas que se comunican con las bases de datos no son pruebas de unidad por definición. La razón principal de esto es el punto que usted menciona: las pruebas unitarias deben ser simples y fáciles de ejecutar.

Esto no quiere decir que no debería código de la base de datos de prueba. Pero no desea considerarlos unidad pruebas. Por lo tanto, si realiza alguna prueba de base de datos, desea separar las pruebas del resto de las pruebas de su unidad.

Answer 3

La solución es Burlarse. Mocks "reemplaza" la conexión. La unidad bajo prueba se "conectará" al simulacro y ejecutará su declaración. El simulacro devuelve resultados normales o.s.e.

Después de la prueba, el simulacro puede darle una lista de todos los métodos, que fueron llamados por la unidad bajo prueba. Easymock.org

Como dijo el otro: La conexión DB no es una prueba unitaria. Así que colóquelo y hágalo a nivel local con los objetos de burla

Answer 4

Usamos una base de datos en memoria (hsqldb) para nuestras pruebas unitarias. En la configuración, lo llenamos con datos de prueba y luego, antes de cada caso de prueba, iniciamos una transacción y después de cada caso de prueba lo retrotraemos a la transacción. Esto significa que cada caso de prueba tiene un inicio limpio de la base de datos.

Answer 5

El costo de la unidad de prueba/TDD es que debe modificar su diseño para que tenga una separación limpia entre la base de datos y la capa de dominio, para que pueda crear una falsificación que le permita crear pruebas que golpear la base de datos.

Pero ese diseño más limpio es solo el comienzo del costo. Después de eso tienes que crear pruebas que te ayuden a hacer que el código funcione correctamente la primera vez y te avise cuando alguien rompa algo que solía funcionar.

Y después de tener un buen diseño fundamental con pruebas que protegen su funcionalidad existente, se encontrará limpiando el código para que sea más fácil trabajar con él, con la confianza de que no está rompiendo las cosas en el camino.

Y así sucesivamente ... Los costos de la unidad de prueba/TDD simplemente se acumulan con el tiempo.

Answer 6

Para Java, es posible que también desee buscar en dbunit. http://www.dbunit.org/

Answer 7

Parece que realmente quiere pruebas funcionales/de integración. Para aplicaciones web, le recomiendo que busque en Selenium o Canoo WebTest.

Estos también son excelentes para automatizar las tareas que realiza en la Web. Tengo una suite de configuración y una suite de eliminación que crean entidades comerciales y prueban a los usuarios a través de la interfaz de administración, así como las pruebas para el sitio orientado al cliente.

Answer 8

Desde que utiliza Doctrina para mi trabajo de base de datos PHP, y desde Doctrina tiene una capa de abstracción de consulta (llamado DQL), puedo cambiar la parte de atrás termina sin tener que preocuparse demasiado por problemas de compatibilidad. Entonces, en este caso para las pruebas de mi unidad, al comienzo de mis pruebas solo cargaría el esquema y los accesorios en un SQLlite db, probaría mis modelos y descartaría el SQLlite db al final de las pruebas.

De esta manera he probado mis modelos y el acceso a los datos para asegurarme de que sus consultas estén formadas correctamente.

Ahora probar la instancia de base de datos específica para asegurarse de que el esquema actual es correcto es una historia diferente y en mi humilde opinión probablemente no pertenezca a las pruebas unitarias, tanto como pertenece a la lista de tareas de implementación.