← Python мануфактура

Конспект і таймкоди

0:00

Інкапсуляція та automation objects

Інкапсуляція ховає складну реалізацію за невеликою public operation. У тестовому проєкті це API clients, database helpers, Page Objects і data objects. Зовнішньому коду важливо знати, яку дію викликати, а не повторювати connection setup, headers, selectors або permission checks.

1:30

`class`, `__init__`, `self` і methods

Class name зазвичай є іменником в однині та пишеться з великої літери. __init__ приймає початковий state, а self.email і self.role належать конкретному object instance. Method is_admin() розміщує перевірку ролі біля даних і не змушує кожен test повторювати user.role == "admin".

3:30

API client як state плюс behavior

UsersApiClient зберігає base_url і token, нормалізує base URL та будує authorization headers і user endpoint. Test створює client один раз і викликає intent-level methods замість ручного складання URL/header у кожному сценарії. Token усе одно не можна друкувати в logs.

4:31

Поліморфізм без зайвої складності

Поліморфізм дозволяє однаковому interface мати різну реалізацію, зокрема через method override. Але одна назва для суттєво різних дій може приховувати code smell. У Python default/keyword arguments часто вирішують просту варіативність без overload hierarchy.

5:32

Page Object і component boundaries

LoginPage.login(email, password) ховає locators і послідовність fill/click за дією користувача. Великий product page можна розкласти на логічні components, наприклад product card або related products, якщо вони мають власну поведінку. Page Object не повинен ставати контейнером усієї test logic.

6:31

Composition замість глибокого inheritance

Наслідування корисне для невеликої справді спільної поведінки, наприклад open() або is_loaded() у base page. Для сторінки, що складається з кількох незалежних components, composition простіша: page тримає потрібні objects і делегує їм роботу. Це уникає multiple inheritance та великих base classes, зміна яких ламає багато несуміжних сторінок.