Як виконують тестові завдання Test Automation Engineer

[@АндрейГончаров-б4ч]

по розділенню на Sourse та Test. Думаю що це повязано з тестуванням самого застосунку Java. Коли пишуться Unit тести вони будуть в папці Test , а в Sourse буде код самого застосунку.

[@leonidvr6455]

Працював на великому проекті. Ми робили педж обджект виключно для описання контролів, а от методи і веріфайкі були в окремому класі. Про прикоміт хук для лінта хотілось би більше почути.

[@MaksymStroievus]

Добавте, будь ласка, лінки на репозиторії

[@MaksymStroievus]

А взагалі такого роду відео, це супер круто 1. Можна побачити як завдання роблять сеньйори, що дозволяє зрозуміти інколи хід думок. 2. Можна побачити хороші рішення, best practice і почути за архітектуру проєкту. І як бонус, це все ще й обговорюють два Ліди, які говорять як можна зробити краще, а як не потрібно. Тут пахне лайком по дефолту.

[@qa_senpai]

Додав в опис до відео ;)

[@nickfwhite4296]

я як зрозумів тут тестові мідлів/сенйорів? було б цікаво подивитися на тестові джунів

[@qa_senpai]

Треба щось придумати по цій темі

[@MarianHotsiy]

Було питання чому використовувався beforeEach і що це можна винести в фікстури. Як на мене таке легше читати, тобто все перед очима і не потрібно гадати, що відбувається за кадром, особливо коли вперше це бачиш.... тут треба взяти поправку на не, що я з фікстурами в playwright не знайомий і пишу на C#. IMHO чим більше інфи про тест у файлі з тестом, тим легше це аналізувати, особливо, якщо нема багато досвіду роботи з технологією і тд..

[@newalyaska5668]

Я не сеньор, але коли виконувала тестове завдання в свою теперішню компанію щось мені не сподобалося в тому тестовому, переробила і на співбесіді їм про то сказала)))по життю ніколи не наїзжаю....якщо бачу що можна інакше(не краще, а просто інакше і можливо більш оптимізованіше)

[@qa_senpai]

Оце топ, я б вас теж найняв 😉

[@geoffreycollins6627]

продублюю сюди питання з коментів: ​​так а якщо ми робимо типу для "ентерпрайзу" проект, то якщо в нас більше однієї сторінки, нам треба в кожному ПОМі ініціалізувати кукі компонент?. Мені все-таки рішення в першому проекті здається дальновиднішим

[@seekerofsense]

так можна цей метод винести в папку shared-components наприклад або в хелпери... Бейс пейдж це ж абстрактний клас, який не мав би містити в собі якусь імплементацію метода який стосується конкретної пейджі (логін чи хоум, точно не стосується всіх пейджів) про те шо не клікати в кожному тесті, а передавати сторадж... да, але тут можна й бажину пропустити коли шось зламається

[@dantegrek176]

навіщо в кожній сторінці ініціалізувати те що ти робиш один раз? непотрібно. в тебе всі тести за вийнятком тих де ти тестуєш той самий кукі попап вже будуть звільнені від потреба їх аксептати.

[@dantegrek176]

@@seekerofsense щоб не пропустити бажину на фічу з куками треба окремий файл з тестами завести)

[@geoffreycollins6627]

@@dantegrek176 так я про то и кажу. в вашому першому переробленому випадку, у разі якщо будуть ще якісь сторінки окрім Parfume, то треба додавати ту куки модалку в кожний ПОМ

[@geoffreycollins6627]

я б взагалі комбінував рішення в першому і останньому проектах: мав би окремий кукі компонент і додав би його до бейс пейджу один раз

[@Tallleran]

Якщо ви колись будете працювати з англомовними колегами. То вони прям офігіють від слова фікстури. Вибачаюсь але це читається як «фіксча». Не вчіть людей каверкати термінологію.