Как проверить, не вызывает ли удержание кнопки баги или многократные вызовы
Что проверяют
Понимаете ли вы, откуда берутся дубли: действие срабатывает на нажатие, на отпускание или повторяется, пока кнопка зажата. Интервьюер ждёт, что вы проверите не только экран, но и сеть с базой. Следом обычно спрашивают, как должна быть устроена защита и на чьей стороне.
Как отвечать
Сначала уточните ожидаемое поведение. Для кнопки «Оплатить» удержание должно дать ровно одно действие, а у степпера «+» в корзине повтор при удержании может быть фичей, и тогда проверяют скорость повтора, остановку при отпускании и верхний предел.
Сценарии, которые стоит пройти:
- долгое нажатие мышью или пальцем: действие одно, на мобильных не всплывает контекстное меню и не выделяется текст;
- увод курсора или пальца с кнопки до отпускания: действие не выполняется, так ведут себя нативные кнопки;
- удержание Enter на кнопке в фокусе: автоповтор клавиатуры шлёт серию нажатий и может дать серию кликов;
- быстрые повторные клики и двойной тап;
- медленная сеть: троттлинг в DevTools растягивает ответ, и окно для повторного нажатия становится большим.
Дубли ловят на вкладке Network в DevTools, а для мобильного приложения через прокси вроде Charles или mitmproxy: там видно, сколько запросов реально ушло. Затем проверьте результат в базе или в админке: один заказ, одно списание. В автотестах удержание воспроизводят парой mouse.down() и mouse.up() с паузой в Playwright или жестом через W3C Actions в Appium, а в конце считают перехваченные запросы.
Где спотыкаются
Смотрят только на интерфейс: уведомление показалось одно, значит всё хорошо. А на бэкенд ушло три запроса, и заказов в базе тоже три.
Проверяют на быстром локальном стенде, где ответ приходит за 50 мс и нажать повторно просто не успеваешь.
Предлагают как исправление только debounce или блокировку кнопки. Это нужная защита в интерфейсе, но запрос можно повторить и мимо него. Для платежей и других необратимых действий нужен ключ идемпотентности на сервере, и в баг-репорте это стоит указать.