В tv_stale_guard правка человека появляется до сравнения. На тестовой копии MODX с MySQL можно запустить запрос с ожидаемым значением TV и поставить его на паузу сразу после успешного сравнения, перед записью. Из второго сеанса сохранить другое значение этого поля через админку. Если сохранение прошло, продолжить первый запрос и проверить, что он сообщает о конфликте, а чтение из отдельного сеанса показывает правку второго. Если админка ждёт блокировку, стоит зафиксировать это как отдельный исход и ограничить время ожидания, чтобы тест не завис.
На тестовом проекте я бы проверил потерю ответа после создания issue. Закрепите за отчётом метку, которая попадёт в описание задачи. Сохраните номер созданной задачи отдельно для сверки, а ответ агенту не передавайте. Повторите обработку того же отчёта с той же меткой. Сымитируйте пустой результат первого поиска. Отчёт должен остаться на сверке. Когда поиск найдёт задачу, агент должен вернуть исходный номер. По журналу проверьте, что запрос на создание был один.
Для пакета «новое поле + права на него» я бы проверил сбой посередине переноса: на стенде сымитировать отказ записи прав после записи поля. Если пакет должен применяться целиком, после сбоя поля быть не должно, а права должны остаться прежними. После устранения сбоя тот же пакет должен добавить поле один раз: нужная роль его видит, другая — нет. Так проверка поймает частичный перенос, даже если повтор не создаёт дублей.
В истории с Confluence я бы записывал при каждой попытке публикации ревизию инструкций, которые агент для неё загрузил. Если скрипт публикации обновляется отдельно, полезна и его версия. Когда код пытается прочитать токен из переменной окружения, пусть он добавляет в ту же запись, увидел ли переменную (только да или нет). При сбое эту строку можно приложить к обращению, а после отката сверить загруженную ревизию с той, на которую откатывались.
В tv_stale_guard правка человека появляется до сравнения. На тестовой копии MODX с MySQL можно запустить запрос с ожидаемым значением TV и поставить его на паузу сразу после успешного сравнения, перед записью. Из второго сеанса сохранить другое значение этого поля через админку. Если сохранение прошло, продолжить первый запрос и проверить, что он сообщает о конфликте, а чтение из отдельного сеанса показывает правку второго. Если админка ждёт блокировку, стоит зафиксировать это как отдельный исход и ограничить время ожидания, чтобы тест не завис.
На тестовом проекте я бы проверил потерю ответа после создания issue. Закрепите за отчётом метку, которая попадёт в описание задачи. Сохраните номер созданной задачи отдельно для сверки, а ответ агенту не передавайте. Повторите обработку того же отчёта с той же меткой. Сымитируйте пустой результат первого поиска. Отчёт должен остаться на сверке. Когда поиск найдёт задачу, агент должен вернуть исходный номер. По журналу проверьте, что запрос на создание был один.
Для пакета «новое поле + права на него» я бы проверил сбой посередине переноса: на стенде сымитировать отказ записи прав после записи поля. Если пакет должен применяться целиком, после сбоя поля быть не должно, а права должны остаться прежними. После устранения сбоя тот же пакет должен добавить поле один раз: нужная роль его видит, другая — нет. Так проверка поймает частичный перенос, даже если повтор не создаёт дублей.
В истории с Confluence я бы записывал при каждой попытке публикации ревизию инструкций, которые агент для неё загрузил. Если скрипт публикации обновляется отдельно, полезна и его версия. Когда код пытается прочитать токен из переменной окружения, пусть он добавляет в ту же запись, увидел ли переменную (только да или нет). При сбое эту строку можно приложить к обращению, а после отката сверить загруженную ревизию с той, на которую откатывались.