En primer lugar, hay un error en su implementación. Si una consulta falla, la transacción actual se revierte automáticamente y luego se cierra. Entonces, a medida que continúe ejecutando consultas, no estarán dentro de una transacción (se comprometerán con la base de datos). Luego, cuando ejecutas Rollback , fallará silenciosamente. De los Documentos de MySQL
:
Rolling back can be a slow operation that may occur implicitly without the user
having explicitly asked for it (for example, when an error occurs).
El comando explícito ROLLBACK solo debe usarse si determina en la aplicación que necesita revertir (por razones distintas a un error de consulta). Por ejemplo, si está deduciendo fondos de una cuenta, retrocederá explícitamente si descubre que el usuario no tiene fondos suficientes para completar el intercambio...
En cuanto a probar las transacciones, copio la base de datos. Creo una nueva base de datos e instalo un conjunto de "datos ficticios". Luego ejecuto todas las pruebas usando una herramienta automatizada. La herramienta realmente confirmará las transacciones y forzará las reversiones, y verificará que el estado esperado de la base de datos se mantenga durante las pruebas. Dado que es más difícil conocer programáticamente el estado final de una transacción si tiene una entrada desconocida para la transacción, la prueba de datos en vivo (o incluso copiados) no será fácil. Puede hacerlo (y debe hacerlo), pero no dependa de esos resultados para determinar si su sistema está funcionando. Utilice esos resultados para crear nuevos casos de prueba para el probador automatizado...
