<![CDATA[
# Програма
## Вступ
* Як проходити практикум?
* Необхідні знання перед стартом
## Практикум
* Введення в Selene
* Швидкий Старт. Початкові умови, залежності, перші кроки і документація
* Selene в дії
* Завдання: Selene та CSS-селектори
* Питання
* Жорсткі чи слабкі локатори? Крихкість і стабільність локаторів
* Локатори, автоматично згенеровані в інспекторі, чи підібрані вручну?
* Коли виносити локатори в окремі змінні і/або функції чи методи?
* Як знайти елемент зі списку однотипних елементів по потрібному тексту його внутрішнього елемента (CSS)?
* Рев'ю
* Огляд завдання
* Структура git-проекту (poetry)
* Іменування тестів
* Структурна інформація в імені тест-кейсу
* Структурна інформація в імені тест-суіту
* Порушення домовленостей по іменуванню
* Ім'я тест-кейсу не чітко відображає ціль тестування
* Ім'я тест-суіту не чітко відображає ціль тестування
* Поради
* ⇩Розв'язок⇩
* Структура і коментарі
* Коментарі що не додають цінності
* Коментарі що дублюють код, який може змінитись з часом (як то тестові дані)
* Занадто технічні коментарі
* Коментарі що роблять код занадто багатослівним перекриваючи його структуру
* Нечітка тест-логіка через зависоку «щільність» коду (без розділення блоків, наприклад пустими * рядками)
* Нечітка тест-логіка через зависоку «розрідженість» коду (забагато пустих рядків)
* Неконсистентність в структурі
* Поради
* ⇩Розв’язок⇩
* E2E тільки з пустими рядками для розділення на блоки
* E2E з коментарями як заголовками про покриття плюс для розділення на блоки
* E2E з коментарями як заголовками про покриття плюс пустими рядками для розділення на блоки
* E2E з коментарями в стилі BDD як заголовками про покриття плюс пустими рядками для розділення на блоки
* E2E з коментарями як заголовками про покриття, пустими рядками для розділення на блоки і виділення перевірок всередині
* Атомарні тести без коментарів
* Атомарні з коментарями, що структурують код в стилі BDD
* Атомарні з коментарями, що структурують код в стилі BDD плюс пусті рядки для додаткового виділення блоків
* Атомарні з коментарями про покритий функціонал, що структурують код в стилі BDD плюс пусті рядки для додаткового виділення блоків
* Атомарні з коментарями про покритий функціонал, що структурують код в стилі BDD, з пустим рядками для додаткового виділення блоків та опущеною перевіркою в блоці передумови тесту
* Iнші проблеми з читабельністю
* s проти browser.element
* Подвійні лапки
* Використання занадто загальних і тому не точних тегів чи стандартних атрибутів типу type
* Не цілезорієнтовані атрибути в селекторах
* Занадто багатослівні і громіздкі селектори
* Заплутане використання типу атрибуту в селекторі
* Заплутане використання пробілів в CSS-селекторах
* Неконсистентні локатори
* Не ясні занадто короткі селектори
* Стабільні локатори проти крихких
* Динамічно згенеровані атрибути в селекторах
* Крихкі селектори з прив’язкою до тегів
* Крихкі селектори з прив’язкою до точного шляху
* parent>child проти parent descendant
* nth-child проти nth-of-type
* Пошук по класу проти пошуку по CSS-класу
* Перевірки
* Пропущений виклик методу should
* Перевірка одного елементу замість всього списку
* Феншуй Коду
* Зайві пусті рядки
* Занадто довгі рядки
* Завдання: Selene та XPATH-селектори *\[ В РОЗРОБЦІ... \]*
* Питання
* Як в XPATH шукати по одному CSS-класу, а не по всьому значенню відповідного атрибуту?
* Як знайти елемент зі списку однотипних елементів по потрібному тексту його внутрішнього елементу (XPath)?
* Рев'ю
* Крихкі жорсткі локатори. Надмірність в шляхах - прив'язка до тегу
* Подвійні лапки всередині подвійних лапок
* Використання position() для пошуку елемента по індексу
* Пошук елемента по індексу замість пошуку по тексту
* Нюанси пошуку по CSS-класам, батьківським елементам
* Розбиття коду і його зв'язність
* Завдання: Рефакторинг складних XPath-селекторів *\[ В РОЗРОБЦІ... \]*
* Питання
* Де краще зберігати допоміжні функції для побудування складних XPath-селекторів? (Стратегія зберігання функцій)
* Важливість імен
* Яку саме частину довгого, складного XPath селектора потрібно виносити в окремі функції, а які ні?
* Рев'ю
* Надмірність імен
* Незрозумілі, неповні імена допоміжних функцій
* Дублювання коду. Принцип DRY
* Параметризація функцій
* Іменування функцій. Поради, стилі і домовленості.
* Структуризація коду. Що де має жити в межах проекту.
* Оптимізація імпортів
* Інтерполяція та конкатинація
* Простота коду. Знайомство з YAGNI, KISS
* Завдання: XPath DSL *\[ В РОЗРОБЦІ... \]*
* Можливості ООП у порівнянні з Модульною і Процедурною парадигмою в програмуванні
* Побудова DSL
* Загальні часті питання та відповіді (FAQ)
* Тестова логіка
* Рекомендації та загальноприйняті домовленності в підборі імен
* Ім'я модуля?
* Ім'я класу?
* Ім'я пакету python?
* Ім'я функції або методу?
* Ім'я змінної?
* Ім'я константи?
* Ім'я тест-модулю або тест-класу?
* Пакети в тестовому проекті?
* Тест-функції і тест-методи?
* Рекомендації для покращення читабельності імен
* Шаблон побудови імені функції або методу
* Шаблон побудови імені змінної
* Використання загальноприйнятої термінології
* Не зловживати скороченнями
* Термінологія в контексті
* Говоримо мовою місцевих
* Недвозначність
* Лаконічність
* Не повторювати те, що вже задано контекстом
* Простота
* Матеріали, які рекомендуються до самостійного освоєння
* Статті
* Книги
* Блоги
]]>
