Primeiro de tudo, há um bug em sua implementação. Se ocorrer um erro de consulta, a transação atual será automaticamente revertida e fechada. Portanto, à medida que você continua a executar consultas, elas não estarão dentro de uma transação (elas serão confirmadas no banco de dados). Então, quando você executa
Rollback , ele falhará silenciosamente. Dos documentos 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).
O comando explícito
ROLLBACK só deve ser usado se você determinar no aplicativo que precisa reverter (por outros motivos que não um erro de consulta). Por exemplo, se você estiver deduzindo fundos de uma conta, você reverterá explicitamente se descobrir que o usuário não tem fundos suficientes para concluir a troca... Quanto a testar as transações, copio o banco de dados. Eu crio um novo banco de dados e instalo um conjunto de "dados fictícios". Então eu executo todos os testes usando uma ferramenta automatizada. A ferramenta realmente confirmará as transações e forçará rollbacks e verificará se o estado esperado do banco de dados é mantido durante os testes. Como é mais difícil saber programaticamente o estado final de uma transação se você tiver uma entrada desconhecida para a transação, testar dados ativos (ou mesmo copiados de ativos) não será fácil. Você pode fazer isso (e deve), mas não dependa desses resultados para determinar se o seu sistema está funcionando. Use esses resultados para criar novos casos de teste para o testador automatizado...
