¿Cómo hacer pruebas unitarias para asegurar que el procedimiento almacenado está eliminando la fila de la base de datos?

Soy nuevo en pruebas unitarias y necesito ayuda con lo siguiente.

He creado un pequeño proyecto para ayudarme a aprender cómo hacer pruebas unitarias. La funcionalidad para uno de los formularios en mi aplicación elimina un usuario de la tabla Usuario (y otras filas en las tablas de mapeo).

Actualmente, la prueba unitaria que he creado para probar esto configura los objetos requeridos y luego llama al método de reglas de negocio (pasando la identificación del usuario) que llama al método de acceso a datos para ejecutar el procedimiento almacenado que elimina las filas en las tablas.

¿Es este el método correcto para probar si algo se está eliminando correctamente? ¿Debería el método de prueba / configuración de la unidad insertar primero algunos datos de prueba que la prueba de la unidad luego borra?

c# unit-testing

— Theomax
fuente

Respuestas:

En mi humilde opinión, si recién está comenzando a aprender las pruebas unitarias, es mejor dejar las bases de datos fuera de la imagen por ahora. Los datos en una base de datos son más difíciles de probar; de hecho, cuando está probando código que realiza llamadas directas a una base de datos, ya no es una prueba unitaria sino una prueba de integración .

Puede código de prueba unidad de manipulación de una base de datos, pero requiere más esfuerzo y herramientas, incluidos los marcos adicionales - como DBUnit en el mundo Java -, interfaces, se burla , etc., que son temas más avanzados.

— Péter Török
fuente

Gracias, mi pregunta probablemente parece muy novata. ¡Supongo que una de las cosas que encuentro difíciles es decidir incluso qué probar! Por lo tanto, por qué pensé que probar datos en la base de datos no era muy diferente a escribir pruebas que afirman valores devueltos por métodos, etc.

— Theomax

¡Y escribir pruebas unitarias para el pequeño proyecto que creé me ha hecho darme cuenta de que gran parte del código debe moverse a la capa de reglas de negocio en lugar de estar detrás del código de formularios! Este debe ser un ejemplo de uno de los beneficios de las pruebas untit?

— Theomax

@aspdotnetuser: ¡Correcto! El código comprobable es el código mantenible.

— Kevin Cline

when you are directly testing a DB, it isn't a unit test anymore but integration test.¿Estás seguro? Si está probando cómo funciona una aplicación con una base de datos, es una integración segura, pero la unidad que prueba una base de datos es posible: blogs.msdn.com/b/atverma/archive/2010/07/28/…

— StuperUser

@StuperUser, mi fraseo no estaba claro, gracias por los comentarios :-) Lo que quise decir era probar, por ejemplo, el código C # que depende directamente (y hace llamadas a) un DB. Las pruebas unitarias, por ejemplo, los procedimientos almacenados dentro de una base de datos es un tema diferente. Actualicé mi respuesta anterior para aclarar.

— Péter Török

Será mucho más fácil escribir pruebas unitarias para procedimientos almacenados SQL en SQL. Echa un vistazo a tSQLt . Evite volver a probar los procedimientos almacenados en sus pruebas de unidad C #; Siga los consejos de Ratchet Freak y simule la base de datos para probar el código C #.

— Kevin Cline
fuente

debe burlarse de la base de datos (abstraída) mientras prueba el formulario

esencialmente proporcionando una implementación ficticia que hace el mínimo necesario para completar las pruebas

de esta manera, cuando llame a enviar en el formulario, podrá ver si se llama a deleteUser en el acceso a datos

— monstruo de trinquete
fuente