Как удобно тестировать корректную обработку состояния гонки в laravel?

Question

[Антон Антон]

Простейший случай - когда на двух устройствах пытаются зарегистрироваться одновременно с одним email? Но вообще такого в реальной жизни может быть много (например на фронте забыли заблокировать кнопку отправки запроса и пользователь жмакает её два раза и т.п.)
https://laravel.com/docs/master/testing#running-te... прочитал но, кажется, это не то.

Comments

[Everything_is_bad]

а почему тут должна возникать гонка? просто так она не возникает, ее может породить какой-то код, но сам код тут не показан.

[Антон Антон]

Everything_is_bad, с регистрацией может быть не самый очевидный пример, часто email имеет уникальный индекс и идет ошибка, да (но и это надо протестировать). Но бывают случаи, когда пользователь может быть удален и создан заново, например при регистрации по номеру телефона - когда пользователь долго не пользуется номером и потом номер передается другому человеку. Тогда признак уникальности надо снять и добавить SoftDeletes.

Или с формированием заказа из корзины на двух устройствах одновременно (да даже и с одного при двойном нажатии).

Да мало ли случаев. Я спрашиваю про общий подход - есть ли удобный вариант в инфраструктуре laravel или надо изобретать что-то?

[Everything_is_bad]

Антон Антон, ну и что что есть уникальный индекс и прочее тут описанное, как это влияет на появление состояние гонки? еще раз, какая-та кривая реализация может его вызвать, но только конкретная реализация.

[Антон Антон]

Everything_is_bad, ну да. и вот это и надо протестировать - что все нужные блокировки выставляются, что ненужные - не выставляются. Что не возникает дедлоков и лишних задержек при параллельной работе.

[Everything_is_bad]

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

[Антон Антон]

Everything_is_bad, ну вот кейс - был эндпоинт, в начале было получение информации из БД, проверка, если ок, то создание и возврат данных. потом в процессе добавилось обращение к внешнему сервису, причем добавили его в середину между проверкой и созданием (зачем два раза базу дергать, на создание и обновление?) сущности.

при реальной эксплуатации заметили двойные сущности в БД, стали разбираться, получилось понять, как такое возможно и вставить нужное.

В принципе, замедлить запросы можно на уровне всей системы, переопределением своей реализацией соответствующих фасадов (да хотя бы и просто sleep в нужные места, хоть и костыль). Задача в добавлении тестов для проверки корректности внесенных изменений для исправления подобных ошибок, выявленных в эксплуатации и для "упреждающего" тестирования потенциально проблемных мест при параллельной работе нескольких пользователей. И встраивание этого в общий процесс тестирования (в идеале - в php artisan test)

[Антон Антон]

т.е. как удобно сделать "красный тест", воспроизводящий ошибку?