Prima di tutto, c'è un bug nella tua implementazione. Se una query va in errore, la transazione corrente viene automaticamente annullata e quindi chiusa. Quindi, mentre continui a eseguire query, non saranno all'interno di una transazione (saranno vincolate al DB). Quindi, quando esegui Rollback , fallirà silenziosamente. Dai documenti 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).
Il comando esplicito ROLLBACK dovrebbe essere utilizzato solo se si determina nell'applicazione che è necessario eseguire il rollback (per motivi diversi da un errore di query). Ad esempio, se stai deducendo fondi da un account, eseguiresti esplicitamente il rollback se scopri che l'utente non dispone di fondi sufficienti per completare lo scambio...
Per quanto riguarda il test delle transazioni, copio il database. Creo un nuovo database e installo un set di "dati fittizi". Quindi eseguo tutti i test utilizzando uno strumento automatizzato. Lo strumento eseguirà effettivamente il commit delle transazioni e forzerà i rollback e verificherà che lo stato del database previsto venga mantenuto durante i test. Poiché è più difficile conoscere in modo programmatico lo stato finale di una transazione se si dispone di un input sconosciuto per la transazione, testare i dati in tempo reale (o anche copiati dal vivo) non sarà facile. Puoi farlo (e dovresti), ma non dipendere da quei risultati per determinare se il tuo sistema funziona. Usa questi risultati per creare nuovi casi di test per il tester automatizzato...
