Приходилось ли работать с транзакциями в Java

Что проверяют

Умеете ли вы тестировать то, чего не видно в интерфейсе. Разработчик расскажет, как транзакция устроена, а от тестировщика ждут сценариев, которые доказывают, что откат действительно происходит.

Как отвечать

Начните с того, что проверяете, а не с того, как устроен Spring.

• Атомарность. Нужен управляемый сбой в середине операции: подменённый ответ смежного сервиса, недоступная база, нарушение ограничения на второй вставке. После сбоя идём в базу и убеждаемся, что частичной записи нет: заказ без позиций, списание без движения по остатку.
• Повторы. Клиент повторяет запрос, который на самом деле прошёл. Проверяем идемпотентность по ключу, а не «вроде дублей не видно».
• Конкурентность. Два параллельных запроса к одному объекту. Здесь ловится потерянное обновление, когда чтение и запись разнесены, а ни блокировки, ни версии нет.
• Изоляция. Аномалии полезно знать по именам: грязное чтение, неповторяющееся чтение, фантомы. На PostgreSQL первое не воспроизвести, и это нормальный ответ.

Инструменты простые: прямые запросы к базе после сценария, логи блокировок и взаимных блокировок, любой нагрузочный инструмент для параллельных запусков.

Где спотыкаются

Проверяют только удачный путь. Транзакция существует ради сбоя, и если сбой не воспроизводится намеренно, про откат тест не доказывает ничего.

Заворачивают сам тест в транзакцию с откатом и радуются чистым данным. Такой тест не увидит того, что проявляется на коммите: отложенных ограничений, триггеров, кода, который пишет в отдельной транзакции и после отката теста остаётся в базе.

Смотрят только на ответ API. Сервис вернул ошибку, значит всё откатилось. Совсем не обязательно: строка могла остаться, счётчик уехать, сообщение в очередь уйти. Судить надо по состоянию хранилища, а не по коду ответа.