Tout d'abord, il y a un bogue dans votre implémentation. Si une requête échoue, la transaction en cours est automatiquement annulée puis fermée. Ainsi, pendant que vous continuez à exécuter des requêtes, elles ne seront pas dans une transaction (elles seront validées dans la base de données). Ensuite, lorsque vous exécutez Rollback , il échouera silencieusement. À partir de la documentation 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).
La commande explicite ROLLBACK ne doit être utilisé que si vous déterminez dans l'application que vous devez effectuer une restauration (pour des raisons autres qu'une erreur de requête). Par exemple, si vous déduisez des fonds d'un compte, vous effectuerez explicitement une annulation si vous découvrez que l'utilisateur n'a pas suffisamment de fonds pour effectuer l'échange...
En ce qui concerne le test des transactions, je copie la base de données. Je crée une nouvelle base de données et installe un ensemble de "données factices". Ensuite, j'exécute tous les tests à l'aide d'un outil automatisé. L'outil validera réellement les transactions et forcera les restaurations, et vérifiera que l'état de base de données attendu est maintenu tout au long des tests. Puisqu'il est plus difficile de connaître par programmation l'état final d'une transaction si vous avez une entrée inconnue dans la transaction, tester des données en direct (ou même copiées depuis le direct) ne sera pas facile. Vous pouvez le faire (et devriez), mais ne comptez pas sur ces résultats pour déterminer si votre système fonctionne. Utilisez ces résultats pour créer de nouveaux cas de test pour le testeur automatisé...
