Po pierwsze, w Twojej implementacji jest błąd. Jeśli zapytanie się nie powiedzie, bieżąca transakcja jest automatycznie wycofywana, a następnie zamykana. Tak więc, gdy będziesz kontynuować wykonywanie zapytań, nie będą one znajdować się w transakcji (zostaną przypisane do bazy danych). Następnie, gdy wykonasz Rollback , po cichu zawiedzie. Z dokumentacji 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).
Wyraźne polecenie ROLLBACK powinno być używane tylko wtedy, gdy określisz w aplikacji, że musisz wycofać (z powodów innych niż błąd zapytania). Na przykład, jeśli potrącasz środki z konta, wyraźnie wycofasz się, jeśli dowiesz się, że użytkownik nie ma wystarczających środków, aby zakończyć wymianę...
Jeśli chodzi o testowanie transakcji, to kopiuję bazę danych. Tworzę nową bazę danych i instaluję zestaw "fikcyjnych danych". Następnie wszystkie testy przeprowadzam za pomocą zautomatyzowanego narzędzia. Narzędzie faktycznie zatwierdzi transakcje i wymusi wycofanie zmian oraz sprawdzi, czy oczekiwany stan bazy danych jest utrzymywany podczas testów. Ponieważ trudniej jest programowo poznać stan końcowy transakcji, jeśli masz nieznane dane wejściowe do transakcji, testowanie danych na żywo (lub nawet skopiowanych z rzeczywistych) nie będzie łatwe. Możesz to zrobić (i powinieneś), ale nie polegaj na tych wynikach przy określaniu, czy twój system działa. Wykorzystaj te wyniki do zbudowania nowych przypadków testowych dla testera automatycznego...
