Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
[Дивитися з 15:00](https://www.youtube.com/watch?v=jAl2Qf8Zlyg&t=900s). Паралельні coding agents збільшують output, але потребують більше review. Engineer має одночасно думати про race conditions, ризики, completeness ticket-а, API/data contracts і місце transformation logic. Простий приклад — dates: backend може повернути timestamp, local date або значення з timezone; без єдиного контракту різні screens покажуть різні результати.
Спільний тестовий користувач створює race conditions: паралельні тести змінюють один стан, заважають один одному й роблять результат нестабільним. Найкращий шов — створювати унікального користувача або іншу сутність під конкретний тест чи worker. Фізичне видалення даних може зламати foreign keys та історичні зв'язки з orders, invoices або іншими сутностями. Через це продукт часто застосовує soft delete: запис залишається, але отримує статус deleted/inactive. Для тестових середовищ потрібно знати реальну політику refresh/cleanup; не слід бездумно накопичувати персональні production-дані або копіювати їх без маскування й визначеного строку зберігання.
Сценарій розширюється: після авторизації тест знаходить поле пошуку, вводить `Manufacture Light`, відкриває проєкт і перевіряє заголовок сторінки. Локатори виносяться у змінні, щоб одне й те саме значення використовувалось для кліку та перевірки. Очікування початкового завантаження документа не гарантує готовність динамічного UI. Після кліку Selenium одразу переходить до `find_element()`, тоді як потрібний компонент ще рендериться. У результаті тест падає не через дефект продукту, а через те, що тест швидший за інтерфейс. `is_displayed()` тут не допомагає, якщо сам `find_element()` уже кинув exception. Синхронізацію треба будувати навколо повторного пошуку елемента, а не навколо одноразової перевірки рано знайденого об’єкта.
Locator-based explicit wait вирішує stale reference тим, що на кожній спробі знаходить актуальний DOM-вузол. Це ще одна причина зберігати локатор, а не довгоживучий `WebElement`. Implicit wait радять залишити нульовим і не змішувати з explicit waits: інакше внутрішнє очікування кожного `find_element()` додається до зовнішнього polling, через що реальний timeout стає непередбачуваним. Практичне завдання — зробити `BasePage`, окремий wait helper і Page Object у вибраному locator-based стилі.