Из примеров на поверхности — автоматизированное тестирование web UI на Angular намного проще, если использовать тулзы вроде Protractor. При этом работа пройдет гораздо сложнее, если использовать Selenium. В этом случае он не совсем подходит.
Потужна аналітика, прекрасний мем.
Після 5го також. Під ретраями мається на увазі перезапуск цілого тесту, а не конкретної команди.
Платити не потрібно, дешборд — це звичайна репортилка, ліл.
«Лучше» — суб’єктивне поняття. У кожного інструмента є свої хороші та погані сторони.
Якщо вам потрібен зелений білд, але для цього доводиться ховати провтики тест дизайну / недостатнє знання інструмента / відсутність розуміння як він працює в браузері / флекі-баги самого додатку / нестабільний тестовий стенд за перезапусками — чого б одразу не писати `expect(true).to.be.true` і не паритись?
Дійсно, дякую за уточнення!
Основна проблема будь якого переходу з мови Х на мову Y — основна маса людей чомусь починає займатись натягуванням сови на глобус в стилі «раніше було краще».
Результат: «Я, чувак з 9000 років автоматизації на мові А, приходжу пилити фреймворк на js, записую проміс в змінну, викликаю, а мені в консоль падає якась дічь — ну і фігня цей ваш js, де тут типи, компілятор і оті всі плюшки які були в моїй зоні комфорту? Ну його в баню, давайте далі писати на А, там все простіше».
По хорошому, потрібно відокремлювати інструменти (webdriverjs, puppeteer) і фреймворки. Так як на базі інструментів потрібно пилити велику купу бойлерплейту, але «свою та рідну» — і у разі невдачі, здебільшого це недолік власної архітектури, а не проблема js. Фреймворки, в свою чергу, накладають свої обмеження і trade-offs. На додачу, деякі є обгортками навколо селеніум (wdio, protractor), а деякі є окремими тулами з своїм стайл гайдом, особливостями і концепціями (cypress).
Якщо ж починати перехід з розумінням того, що в js «не все як у людей» і бути готовим до змін — з часом написання і підтримка тестів швидша і простіша за інші мови (особисто порівнював з с#). Якщо ж, наприклад, зрозуміти що хоче Cypress від твого коду — то процес стає ще швидшим ніж на інших js рішеннях. На проекті ганяємо Cypress + cucumber + allure, для тестів логіну окремий скрипт на puppeteer, в тестах авторизація через апі — політ нормальний.
Рекомендую хороший виступ Михайла Боднарчука (автора codeceptjs — фреймворк над селеніум обгортками) про муки вибору інструментарія:
youtu.be/0m7rNBBkezU
P.S. Щодо платних фішок сайпреса — можна спокійно юзати і без їх сервісів, використовуючи як тест раннер з своїм репортером і стратегіями паралелізації. По факту вони просто дають можливість записувати результати паралельних запусків в свій дешборд. Велика частина ішью на гітхабі — купа проблем із застарілою версією їх дефолт браузера Електрон. Якщо запускати в Хромі — все ок.
Нарешті :)
Дякую за дайджест.
P.S. Для тих, хто пропустив цьогорічний SeleniumCamp, вони виклали доповіді на ютуб, енджой:
www.youtube.com/.../UCTGNGRvd6fxpj1F6-7emUJw
Насправді, для маленьких команд Postman шикарне рішення, яке дозволяє вже з мінімальним знанням js пилити автотести. Доступна і паралелізація — описано на гіті постманлабс, досягається викликами ньюмана через лібу async. Альтернативний варіант — powershell скрипт з викликами Start-Job. Навіть в режимі паралельного виконання newman-teamcity-reporter відпрацьовував адекватно і його цілком вистачало.
З коробки доступні lodash (3 версія, для підтримки 4 потрібно викликати через require), moment.js, валідація json схем, cheerio.
З категоричних мінусів — не очевидно в яких випадках енвайрмент persistent, а коли — ні, в деяких кейсах навіть не допомагає виклик api update environment і танці з галочкою в налаштуваннях.
Ну і GUI, який напиляний на електроні і при великих кількостях колекцій/синхронізацій просто загинається і вижирає ресурси.
Тому не зовсім зрозумілі спалахи п’ятих точок деяких коментаторів — для ’входу’ в автоматизацію Postman хороший варіант, а з новим Test API в bdd стилі не проблема ті ж тести перенести згодом в будь-який js тест раннер.
Згоден, конкретизую: чомусь всі статті для автоматизаторів початкового рівня зводяться до написання тестів для UI, оминаючи взагалі API рівень. Якщо ж поєднувати — набагато простіше локалізувати проблему. Саме це і було метою коменту.
Підтримую. Враховуючи, що для покриття API базовими тестами наразі достатньо постмана і знання основ js, одразу пилити кейси для UI-рівня — дорого і довго, та і зафейлений тест є недостатньою інформацією для репорту, зазвичай реальні причини ховаються на нижчих рівнях.
В могилянці на інформатику менший прохідний бал, ніж на програмну інженерію. Ще є прикладна математика. Кардинальної різниці в спеціальностях немає, база хороша + є можливість взяти цікаві вибіркові курси.
Рекомендую зайти в деканат факультету інформатики і уточнити персонально, або з приймальною комісією, там обов’язково підкажуть варіанти вирішення ситуації.
Удачі :)
In Mexico every developer is Senior developer
У MacPaw дедлайн по анкете был до 9 мая и на данный момент они уже отобрали кандидатов.
Тому що по суті, QA — це такий же інженер в команді, як і всі інші, тільки його скоуп задач орієнтований на забезпечення якості і ефективності розробки, починаючи з аналізу вимог і до фінального контролю виконання і автоматизацією цього контролю. Це якраз та людина в команді яка має допомагати розробникам бути ефективними, а не блочить їх перманентним пінг-понгом тікетів, ну якщо там мінорна дичина — візьми і фіксани, нафіга девам перемикати контекст. Навіть якщо доведеться так пару спринтів займатись багофіксом — це може спокійно мати місце, особливо в критичних ситуаціях, коли фокус команди на делівері фіч.
Просто те чим у нас займаються тестувальники — це quality control, зате з личками QA та istqb сертифікатами.