Как проверить онлайн-запись после вайбкодинга на двойную бронь

Как проверить онлайн-запись после вайбкодинга на двойную бронь

Откройте онлайн-запись в двух независимых сеансах браузера и попробуйте занять одно время у одного мастера. Для индивидуального приёма правильный результат такой: сайт подтверждает одну запись, а второму клиенту предлагает выбрать другое время. Но ручной проверки недостаточно: запросы могут прийти по очереди и скрыть ошибку. Ниже разберём, как поручить Claude Code проверку через Playwright, что посмотреть на сервере и какой результат принять перед запуском сайта салона.

Почему сайт записывает двух клиентов на одно время?

Начните с правила: один мастер принимает одного клиента в пределах времени услуги. Если салон допускает групповую запись, сначала определите вместимость. Без этого тесту не с чем сравнивать результат.

Двойная бронь возникает, когда сервер отдельно проверяет свободное время и отдельно создаёт запись. Между этими действиями приходит другой запрос. Оба запроса видят свободный слот, после чего каждый создаёт бронь. Разработчики называют такую ситуацию гонкой запросов.

Кнопка «Записаться» при этом может работать без видимых ошибок. Она блокируется после нажатия, календарь обновляется, страница показывает подтверждение. Но второй клиент открывает сайт в своём браузере, где кнопка ещё активна. Ограничение в интерфейсе не защищает общее расписание.

Проверьте и длительность услуги. Если процедура занимает интервал, запрета на одинаковое время начала недостаточно: две записи с разным началом тоже могут пересечься. В задании на тест укажите мастера, услугу и весь интервал занятости.

Как подготовить проверку без риска для рабочего расписания?

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

  1. Создайте свободный интервал у тестового мастера. Выберите услугу, которая занимает его целиком.
  2. Откройте запись в независимых сеансах. Для ручной проверки подойдут обычное и приватное окна, если они не используют общий вход.
  3. В обоих окнах выберите одного мастера, одну услугу и одно время. Дойдите до последней кнопки подтверждения.
  4. Отправьте обе заявки почти одновременно. Затем обновите страницы и откройте расписание со стороны администратора.

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

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

Как поставить задачу Claude Code и Playwright?

Поручите Claude Code сначала изучить путь заявки: от кнопки на странице до места, где сервер закрепляет время за клиентом. Playwright нужен для действий в браузере и проверки того, что видит посетитель. В русскоязычном руководстве по Claude Code есть ссылка на навык anthropics/skills/webapp-testing для тестирования веб-приложений через Playwright (GitHub — sfrangulov/claude-code-handbook-ru).

Навык помогает организовать проверку, но бизнес-правило всё равно нужно описать. Передайте агенту такой запрос, заменив описание тестовой среды и услуги на свои:

«Проверь двойное бронирование в тестовой среде. Пока не меняй рабочую логику сайта. Создай в Playwright независимые контексты браузера для двух клиентов. Оба должны выбрать одного мастера, одну услугу и один свободный интервал. Доведи их до подтверждения. Организуй отправку запросов на бронирование максимально близко по времени и сохрани ответы сервера. Проверь, что подтверждение получает только один клиент, второй видит понятное сообщение, а в расписании остаётся одна активная запись. Отдельно проверь пересечение интервалов с разным временем начала. Покажи тест, способ запуска и результат».

Независимые контексты нужны, чтобы клиенты не делили состояние входа и настройки сеанса. Две вкладки одного контекста для этого не подходят: сайт может воспринимать их как одного посетителя.

Даже параллельный запуск действий в Playwright не гарантирует, что запросы встретятся в нужном участке серверного кода. Попросите агента показать, как он сближает отправку запросов. Если браузерный тест не воспроизводит гонку, добавьте проверку на уровне сервера, где можно управлять моментом одновременного обращения к одному интервалу.

Чтобы убедиться, что тест действительно ловит дефект, полезно отдельно проверить, что тесты Claude Code находят ошибки. Зелёный отчёт без проверки чувствительности теста ещё не подтверждает защиту от двойной брони.

Что считать исправлением и как принять результат?

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

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

  • Клиент с успешной заявкой видит подтверждение, которое соответствует записи в расписании.
  • Второй клиент получает сообщение о занятом времени и может выбрать другой интервал.
  • Повторный запрос той же заявки после задержки ответа не создаёт ещё одну бронь.
  • Проверка расписания подтверждает отсутствие пересечений у мастера.
  • Тест завершается после всех ответов и проверок, а не сразу после первого подтверждения.

Сверяйте экран с состоянием расписания. Бывает, что интерфейс показывает ошибку, хотя сервер уже создал запись. Тогда клиент повторяет попытку. Проверка повторной отправки нужна отдельно от сценария, где за слот борются разные клиенты.

После исправления сохраните тест в проекте и включите его в проверки при изменениях календаря или логики записи. Для организации такого запуска пригодится инструкция, как запускать проверки после правок Claude Code через хуки. Сами проверки должны работать только с тестовым расписанием.

Если передаёте доработку специалисту, приложите сценарий, способ запуска теста и ожидаемый результат. Такой пакет задаёт конкретный объём работы по проверке сайта после вайбкодинга: воспроизвести конфликт, исправить серверную защиту и подтвердить результат повторным запуском.

Типичные ошибки при проверке двойного бронирования

  • Проверять заявки по очереди. Между ними сервер успевает занять слот, поэтому конфликт остаётся незаметным. Используйте независимые сеансы и согласуйте момент отправки запросов.
  • Считать скрытый слот доказательством защиты. У другого клиента страница могла остаться открытой. Повторите сценарий без обновления его календаря перед отправкой.
  • Проверять только одинаковое начало. Для услуг разной длительности добавьте сценарий, в котором интервалы пересекаются частично.
  • Исправлять только интерфейс. Блокировка кнопки ограничивает действия на одной странице, но не решает конфликт между клиентами. Проверьте отказ на стороне сервера.
  • Принимать отсутствие ошибки за доказательство. Сохраните ответы обоих запросов и проверьте итоговое расписание, даже если браузерный тест завершился успешно.

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