Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
На системному рівні перевіряється вже розгорнута система. Тут корисно розділяти UI-сценарії користувача й перевірки системних компонентів або API, що формують дані для інтерфейсу. На багатьох реальних проєктах нижні рівні покриті нерівномірно або майже відсутні. Тому QA не може просто виходити з ідеальної піраміди: потрібен шар перевірок, який дає впевненість у поведінці всієї системи на тестовому оточенні.
Учасники спочатку вчаться складати й запускати тестовий сценарій. Після цього курс поступово пояснює, як працюють типи даних, операції зі строками, повторне використання коду та інші конструкції, які вже зустрілися в реальній роботі. Саме з цього підходу виникає питання: якщо класична піраміда тестування радить мати більше нижньорівневих тестів, чому курс починається з UI, а не з API.
`LoginPage.login(email, password)` ховає locators і послідовність fill/click за дією користувача. Великий product page можна розкласти на логічні components, наприклад product card або related products, якщо вони мають власну поведінку. Page Object не повинен ставати контейнером усієї test logic.
Експеримент показує, що `to_have_text()` може успішно знайти текст у прихованому DOM-елементі. Отже, така перевірка не доводить, що користувач бачить проєкт після фільтрації. Для цього сценарію точніша перевірка — `to_be_visible()`. Висновок узагальнюється: assertion треба обирати за реальною вимогою. Якщо контракт про видимість — перевіряємо видимість; якщо про текстове значення незалежно від відображення — тоді `to_have_text()`.