Pruebas unitarias: base de datos y dispositivos

Question

Estoy empezando a realizar pruebas unitarias y no veo una manera fácil de hacer muchos casos de prueba debido a la interacción con una base de datos.

¿Hay un método/proceso estándar para la prueba unitaria donde se requiere acceso a la base de datos (lectura y escritura) para hacer las pruebas?

Lo mejor que se me ocurre hasta ahora es tener un archivo de configuración utilizado para arrancar mi aplicación usando una conexión db diferente y luego usar el método de inicio para copiar el db activo a un db utilizado de forma aislada para las pruebas?

¿Estoy cerca? ¿O hay un mejor enfoque para esto?

Answer 1

Su lógica comercial no debe interactuar directamente con la base de datos. En su lugar, debe atravesar una capa de acceso a los datos que puede simular y simular en el contexto de las pruebas unitarias. Busca marcos burlones para burlarte. Sus pruebas no deben depender de ninguna base de datos. En su lugar, debe especificar los datos devueltos de su capa de acceso a datos explícitamente, y luego asegurarse de que su lógica comercial se comporte correctamente con esa información.

La prueba de que el programa funciona con un DB adjunto es más una prueba de integración, y esos tienen muchos costos asociados. Son más lentos (por lo que es más difícil ejecutarlos cada vez que compila) y más complicados (por lo que requieren más tiempo y esfuerzo para mantenerse). Si puede realizar pruebas de unidad más simples, le recomiendo que lo haga primero. Más tarde, puede agregar pruebas de integración que también podrían usar la base de datos, pero obtendrá el mayor valor de agregar pruebas de unidades más simples primero.

Answer 2

En cuanto a la prueba de unidad, creo que lo que funcione para usted en la práctica es el camino a seguir. Es importante que las pruebas unitarias le den algún valor y mejoren la calidad de su sistema y su capacidad para desarrollarlo y mantenerlo.

Sugeriría que probablemente no desea copiar el db en vivo a su db de prueba. Probablemente no haya garantías de que su base de datos en vivo contenga datos adecuados que harán que sus pruebas unitarias se ejecuten consistentemente. Las pruebas unitarias deberían probar que tu código funciona, no deberían probar que la base de datos en vivo contenga datos adecuados que los hagan pasar, porque como está en vivo, tus usuarios podrían cambiar el contenido para que tus pruebas fallen. .

Su código de prueba unitaria probablemente debería completar su prueba db con los datos necesarios que simulan los escenarios para los que desea escribir las pruebas unitarias. Estuve jugando con el código de Ruby on Rails hace unos años; el marco de prueba para eso tendría una clase de prueba que configuraría el DB con algunos datos falsos, luego se escribirían varios métodos de prueba de la clase para correr contra esos datos, y el método de eliminación eliminaría los datos de la base de datos. Por lo tanto, las diferentes clases de prueba (o a veces las personas las llaman fixturas) se ejecutarían contra una determinada configuración de datos, lo que significaba que podría ejecutar una serie de pruebas contra la misma configuración de datos en lugar de crearla para cada caso de prueba que quisiera ejecutar. La configuración de los datos para cada prueba podría terminar haciendo que las pruebas se ejecuten lentamente, de modo que se aburra de esperar a que se ejecuten y deje de molestarse con ellas.