---

Вот текст для задачи — можно вставлять как есть или подрезать под формат трекера:

---

**Дата:** [сегодняшняя дата]
**Тема:** Анализ существующих автотестов ПИАО перед объединением в общий пул с выгрузкой в Excel

Сегодня провёл аналитическую работу по 3 (из 36) уже написанных автотестов — детально разобрал код, сравнил используемые механики между собой, чтобы понять, что можно унифицировать перед объединением всех тестов в общий прогон с выгрузкой результатов в Excel (по аналогии с текущим чек-листом утренней проверки).

**Что выявлено:**

1. **Ожидание загрузки отчёта.** В тестах используются две разные механики: часть тестов явно ждёт исчезновения маски загрузки (через `ExpectedConditions.invisibilityOfElementLocated` по селектору маски, с таймаутом), другая часть — просто фиксированная пауза (`Thread.sleep`) без проверки реального состояния загрузки. Решение: привести все тесты к варианту с ожиданием исчезновения маски — он надёжнее (не зависит от скорости сети/сервера) и позволяет замерять реальное время загрузки отчёта.

2. **Проверка ошибки загрузки отчёта.** Часть тестов проверяет только один тип блока с ошибкой, другая часть — дополнительно проверяет второй тип (всплывающие сообщения). Решение: унифицировать под более полный вариант проверки (оба типа), чтобы не пропускать ошибки, которые отображаются во всплывающем окне.

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

4. **Проверка календаря-фильтра** — присутствует не во всех тестах, но это не расхождение логики, а особенность конкретных отчётов (не для всех отчётов это применимо). Оставляем как есть, без унификации.

5. **Дублирование кода.** Логика авторизации, переключения в iframe, открытия/закрытия окна «Справка», разбора правил проверки дат сейчас продублирована в каждом из 36 файлов почти без изменений. При объединении в общий прогон и выгрузку в Excel это дублирование нужно убрать — вынести в общий переиспользуемый набор методов, чтобы правки (например, изменение выбранной механики ожидания) вносились в одном месте, а не в 36.

6. **Критерий "тест пройден".** Итоговое условие успеха теста (`allGood`) в разных файлах собрано по-разному (где-то учитывается календарь, где-то — нет, где-то дополнительно требуется наличие хотя бы одного совпавшего источника). Нужно свести к единой формуле с учётом того, что не все проверки применимы к каждому отчёту.

**К чему пришёл / план дальнейшей работы:**

- Общую логику (логин, переключение в iframe, ожидание загрузки по маске, проверка ошибки, работа со справкой, движок правил проверки дат) вынести в один общий переиспользуемый класс/набор методов, а не держать в каждом тесте отдельно.
- Каждый отчёт свести не к отдельному большому классу с собственным `main()`, а к компактному описанию (URL, набор правил по источникам, нужна ли проверка календаря) — сама логика прогона при этом общая для всех отчётов.
- Ввести единую структуру результата проверки (проверяемый пункт / ожидаемое / фактическое / статус), чтобы каждая проверка превращалась в одну строку в Excel, без необходимости переписывать вывод под каждый отчёт отдельно.
- Результаты всех тестов собирать в один Excel-файл в конце прогона (по структуре, близкой к текущему чек-листу утренней проверки), при этом сохранить возможность запускать проверку по одному конкретному отчёту отдельно — для этого и общий раннер, и одиночный запуск будут использовать одну и ту же общую логику, просто с разным набором входных отчётов.
- Логин/пароль и путь к chromedriver вынести из кода в один общий конфиг вместо копии в каждом из 36 файлов.

**Дальше по плану:** провести такой же разбор оставшихся тестов (сейчас разобраны 3 из 36 как репрезентативная выборка), уточнить набор используемых инструментов сборки проекта, и приступить к вынесению общей логики в единый класс/библиотеку с последующим подключением выгрузки в Excel.