AutotestЯк
Қайта жіберілді:
Hot testing Channel
23.04.202514:48
#діскорд 18:00 сьогодні буде остаточний розйоб Playwright MCP сервера
Та порівняємо Windsurf/Cursor з JetBrains IDEs + Julia
https://discord.gg/JeeAakd5?event=1364312617640001657
Та порівняємо Windsurf/Cursor з JetBrains IDEs + Julia
https://discord.gg/JeeAakd5?event=1364312617640001657
15.03.202411:07
Який потрібен софт, щоб допомогти громаді самоорганізуватися та почати вирішувати свої проблеми?
Один з проектів, які можна обрати на Міському таборі для підлітків від школи Майбутні на весняних канікулах — це розробка таск-менеджера для громад.
Ми зберемо команду підлітків для розробки таск-менеджера, який зможе використовувати будь-яка політична спільнота — від шкільного самоврядування до об'єднаної територіальної громади. В режимі хакатону розробимо і запустимо продукт та почнемо тестувати його прямо на таборі.
Як громада може визначити свої проблеми і потреби? Хто в громаді може взятися за пошук рішення? До вирішення яких задач треба залучати державу, а з якими проблемами можна впоратися своїми силами? Який сервіс і софт потрібні, щоб громада самоорганізувалася? А що потрібно окрім софту? — це питання, над якими працюватимемо.
Проєкт будемо створювати за ментороством політологів, правників та власне мене, Яші Крамаренко 😇
🗓️ Міський табір триватиме на весняних канікулах з 25-29 березня в приміщенні школи на Подолі.
Опис інших проєктів і реєстрація на табір на сайті🕹️
Один з проектів, які можна обрати на Міському таборі для підлітків від школи Майбутні на весняних канікулах — це розробка таск-менеджера для громад.
Ми зберемо команду підлітків для розробки таск-менеджера, який зможе використовувати будь-яка політична спільнота — від шкільного самоврядування до об'єднаної територіальної громади. В режимі хакатону розробимо і запустимо продукт та почнемо тестувати його прямо на таборі.
Як громада може визначити свої проблеми і потреби? Хто в громаді може взятися за пошук рішення? До вирішення яких задач треба залучати державу, а з якими проблемами можна впоратися своїми силами? Який сервіс і софт потрібні, щоб громада самоорганізувалася? А що потрібно окрім софту? — це питання, над якими працюватимемо.
Проєкт будемо створювати за ментороством політологів, правників та власне мене, Яші Крамаренко 😇
🗓️ Міський табір триватиме на весняних канікулах з 25-29 березня в приміщенні школи на Подолі.
Опис інших проєктів і реєстрація на табір на сайті🕹️
11.03.202414:34
AI-Powered Test Automation, це вам не півники смоктунці полизувать) У цю середу, 13го березня о 19:00, обскакаємо virtuoso.qa, і подивимось де він на шкалі між мустангом 🐴 і ... поні 🐎 (нехай всі поні мене пробачать... 😇)
Посилання на live stream скину уже в середу десь там за годинку до старту... або підпишіться на канал у ютубі щоб не пропустити, канал зветься так само як цей, шукайте autotestyak 😉
Посилання на live stream скину уже в середу десь там за годинку до старту... або підпишіться на канал у ютубі щоб не пропустити, канал зветься так само як цей, шукайте autotestyak 😉
17.04.202511:07
Тільки помітив cyborg тести @xotabu4-a 😇. Ще не закопувався, але вже пахне тим напрямком про який я фантазував весь свій час у тестуванні. Попросив свою команду швиденько глянути, і чекнути що там і як, враховуючи те що ми наразі на прикладі тестомата студентам своїм синхронізацію автотестів з ТМС показуємо. Нижче репорт по кіборг-тестам з легким порівнянням на тестомат від Олени Долженко. А свої коментарі/короткі-враження залишу в коментарі до посту.
===============
"ТMS не потрібні" — ніби поки занадто гучно сказано, як можна зробити висновок з цієї презентації...
Є в Тестоматі, наприклад, зручні можливості, які не покриваються цією новою "кіборг"-тест-лібою:
- UI для зручного менеджменту тестів, клікаючи по кнопках — фільтрувати, сортувати, присвоювати теги, прив’язувати Jira-тікети, і потім ці теги прилетять і в код автотестів при синхронізації.
- створювати тест-плани за тегами, фільтрами і запускати їх з UI на віддаленому CI-сервері.
- Тестомат підтримує багато мов і тестових фреймворків, а ця нова ліба поки тільки JS+Playwright.
Це в рамках порівняння лише того функціоналу Тестомату, який був нам потрібен у рамках курсу, і відповідно досліджувався. Можливо, у Тестомату ще є багато фіч, якими ми ще не користувалися...
Щодо мануальних тестів — "кіборг"-варіант особисто мені на підставі власного досвіду з менеджменту мануальних тестів сподобався тим, що:
- всі тести — і мануальні, і автоматизовані — зможуть жити в одному проєкті під гітом. Писати, редагувати, рефакторити мануальні можна в улюбленій IDE з усіма її зручностями і фішками. Можна виносити мануальні степи в змінні, методи, робити з ними PO, щоб зручно перевикористовувати тощо.
- можна міксувати степи в одному тесті — автоматизовані, наприклад, прекондішени, посткондішени або самі деякі степи, плюс мануальні степи, де виконання скрипта призупиняється і керування браузером передається тестувальнику, який вручну робить те, що неможливо автоматизувати (наприклад, перевірка якості відеодзвінків, де логін, початок дзвінка можна автоматизувати, а степ, де треба перевірити, як чутно та видно відео, — вже мануальний, або щоб вручну пройти капчу).
Що варто було б прояснити на практиці згодом, коли буде вже реліз:
- для комплексного репортингу (і мануальні, і автоматизовані — в одному репорті) використовується окремий сервер — його треба піднімати та обслуговувати самостійно. І, мабуть, знадобляться значні ресурси, адже записується відео кожного рану, стан браузера на кожному степі, логи консолі...
- ніби ліба буде опенсорсною, тільки AI (за бажанням) платно, поки без подробиць. На сайті лише форма запису у вейт-лист.
Окремо зауважено в подкасті - не "злетить" з мобільними тестами, не буде повного крос-браузер, крос-ОС, обмежена версіями браузерів самого Playwright.
UPDATE від @xotabu4: «Доречі, після підкасту вже поінвестигейтив - з мобільними тестами взлетить, просто не буде такого класного репортингу»
🫶🏻
===============
"ТMS не потрібні" — ніби поки занадто гучно сказано, як можна зробити висновок з цієї презентації...
Є в Тестоматі, наприклад, зручні можливості, які не покриваються цією новою "кіборг"-тест-лібою:
- UI для зручного менеджменту тестів, клікаючи по кнопках — фільтрувати, сортувати, присвоювати теги, прив’язувати Jira-тікети, і потім ці теги прилетять і в код автотестів при синхронізації.
- створювати тест-плани за тегами, фільтрами і запускати їх з UI на віддаленому CI-сервері.
- Тестомат підтримує багато мов і тестових фреймворків, а ця нова ліба поки тільки JS+Playwright.
Це в рамках порівняння лише того функціоналу Тестомату, який був нам потрібен у рамках курсу, і відповідно досліджувався. Можливо, у Тестомату ще є багато фіч, якими ми ще не користувалися...
Щодо мануальних тестів — "кіборг"-варіант особисто мені на підставі власного досвіду з менеджменту мануальних тестів сподобався тим, що:
- всі тести — і мануальні, і автоматизовані — зможуть жити в одному проєкті під гітом. Писати, редагувати, рефакторити мануальні можна в улюбленій IDE з усіма її зручностями і фішками. Можна виносити мануальні степи в змінні, методи, робити з ними PO, щоб зручно перевикористовувати тощо.
- можна міксувати степи в одному тесті — автоматизовані, наприклад, прекондішени, посткондішени або самі деякі степи, плюс мануальні степи, де виконання скрипта призупиняється і керування браузером передається тестувальнику, який вручну робить те, що неможливо автоматизувати (наприклад, перевірка якості відеодзвінків, де логін, початок дзвінка можна автоматизувати, а степ, де треба перевірити, як чутно та видно відео, — вже мануальний, або щоб вручну пройти капчу).
Що варто було б прояснити на практиці згодом, коли буде вже реліз:
- для комплексного репортингу (і мануальні, і автоматизовані — в одному репорті) використовується окремий сервер — його треба піднімати та обслуговувати самостійно. І, мабуть, знадобляться значні ресурси, адже записується відео кожного рану, стан браузера на кожному степі, логи консолі...
- ніби ліба буде опенсорсною, тільки AI (за бажанням) платно, поки без подробиць. На сайті лише форма запису у вейт-лист.
Окремо зауважено в подкасті - не "злетить" з мобільними тестами, не буде повного крос-браузер, крос-ОС, обмежена версіями браузерів самого Playwright.
UPDATE від @xotabu4: «Доречі, після підкасту вже поінвестигейтив - з мобільними тестами взлетить, просто не буде такого класного репортингу»
🫶🏻
14.03.202412:10
На стрімі промайнуло – як набиратись досвіду щоб знайти першу роботу, але здається там я не резюмував мій основний лайф хак: «шукати цікаві оупенсорс проекти чи альфа/бета-версій цікавих апок і гайда тестить, заводить баги». Можна самотужки, навіть в незалежностів від команди таких апок - пройти весь цикл, від декомпозиції функціоналу і побудови функціональної карти + чеклістів, написанню простого власного тест плану (що я буду тестить (скоуп)? як (принципи)? чим (інструменти)? коли?), і аж до автоматизації відповідних сценаріїв, власного прослідковування покриття, заведенню багів і спілкуванню з командою, перепровіркою фіксів, регресії на релізах... І ось вчора список таких апок для першого досвіду поповнився https://github.com/diia-open-source 😉
27.02.202414:24
«А хто лідує цей проект? В плані якості... 🤔 Ніхто? А, ну самі розбирайтесь, знаю я ваші ці стартапи, коли звалюють усе на одного джуна чи мідла»
От не один раз я вже чув таке від тестувальників в контексті вибору нового проекту для роботи. Чомусь багатьох умовно молодих по досвіду інженерів – лякає «повна организація процесу QA з нуля, та ще й коли ти один»... Мені це завжди було важко зрозуміти, бо у самого завжди слина текла на такі проекти – це ж скільки простору для само-розвитку і головне «зробити все саме так як хочеться, і щоб ніхто зверху палки в колеса не вставляв» 😇 А ще – не пам'ятаю щоб коли потрапляв у такі ситуації (а на відсотків 90 лиш в такі я і потрапляв) – то я використовував для власне налаштування процесу щось інше окрім здорового глузду та відкритої структурної комунікації з розробниками для спільного вирішення ключових питань. Раптом дивним чином виявляється, що достатньо взяти відповідальність, проаналізувати проблеми, щиро поділитись ними з іншими членами, сформувати потреби, набрейнстормити по ним варіанти вирішення і дуже швидко звичайна логіка допомагає знайти оптимальне рішення... Не читаючи 100500 книжок по QA, не залучаючи супер-мега консультантів, і так далі 🤡
нЄ?
Давайте от сходимо на TechMeetup від QArea і послухаємо що Артем Григоренко розкаже з цього приводу? Навіть так, саме ви (поки я навіть пости тут постити не встигаю) сходите послухаєте Артема, а тут у коментарях поділитесь зі мною інсайтами, і можливо подискутуєте зі мною по темі:) 🙏🏻
Всі виручені кошти від даного заходу будуть передані на підтримку ЗСУ або інші благодійні цілі. 7 березня о 18:00 👉
https://tech-meetups.qarea.org/more-details-organization-of-the-quality-assurance-process
От не один раз я вже чув таке від тестувальників в контексті вибору нового проекту для роботи. Чомусь багатьох умовно молодих по досвіду інженерів – лякає «повна организація процесу QA з нуля, та ще й коли ти один»... Мені це завжди було важко зрозуміти, бо у самого завжди слина текла на такі проекти – це ж скільки простору для само-розвитку і головне «зробити все саме так як хочеться, і щоб ніхто зверху палки в колеса не вставляв» 😇 А ще – не пам'ятаю щоб коли потрапляв у такі ситуації (а на відсотків 90 лиш в такі я і потрапляв) – то я використовував для власне налаштування процесу щось інше окрім здорового глузду та відкритої структурної комунікації з розробниками для спільного вирішення ключових питань. Раптом дивним чином виявляється, що достатньо взяти відповідальність, проаналізувати проблеми, щиро поділитись ними з іншими членами, сформувати потреби, набрейнстормити по ним варіанти вирішення і дуже швидко звичайна логіка допомагає знайти оптимальне рішення... Не читаючи 100500 книжок по QA, не залучаючи супер-мега консультантів, і так далі 🤡
нЄ?
Давайте от сходимо на TechMeetup від QArea і послухаємо що Артем Григоренко розкаже з цього приводу? Навіть так, саме ви (поки я навіть пости тут постити не встигаю) сходите послухаєте Артема, а тут у коментарях поділитесь зі мною інсайтами, і можливо подискутуєте зі мною по темі:) 🙏🏻
Всі виручені кошти від даного заходу будуть передані на підтримку ЗСУ або інші благодійні цілі. 7 березня о 18:00 👉
https://tech-meetups.qarea.org/more-details-organization-of-the-quality-assurance-process
19.03.202414:23
Нарешті розтаймкодили стрім про Virtuoso, найцікавіше ось:
19:58 чи вміє virtuoso автоматично записати тест
32:31 virtuoso vs python у pycharm
37:00 користь від AI у Virtuoso
37:18 чи не краще copilot?
47:34 нема assert-ів? писати extensions на js о_О?
58:51 очікування vs реальність
1:05:48 Як підтримує API і чи воно треба? (Про те як правильно покривати API тестами)
1:09:20 як функіонал є базовим для таких фреймворків і чи є він тут?
1:11:24 про тестування CRM систем і чому virtuoso тут теж програє
1:12:19 модель конструктора як альтернатива
1:14:18 альтернатива з cucumber
1:19:33 великі проблеми класних фіч virtuoso
1:19:46 про AI testing в codeceptJS
1:20:59 про дебагінг в playwright
1:21:28 сумнівна перевага використання людськоподібної мови
1:23:17 codeceptJS - недоліки дизайну для рефакторингу
1:40:43 скільки часу потрібно, щоб вивчитись і лідувати проект з нуля?
1:43:58 кейс однієї студентки
1:45:20 про важливу навичку в навчанні і як її качати
1:53:47 градація рівнів спеціаліста від джуна до ліда
1:55:47 чи можна і варто всіх залучати до автоматизації?
2:02:03 чому Яша не активний у соц мережах
2:03:39 чим Яша займається?
2:13:50 про мрію в автоматизації
19:58 чи вміє virtuoso автоматично записати тест
32:31 virtuoso vs python у pycharm
37:00 користь від AI у Virtuoso
37:18 чи не краще copilot?
47:34 нема assert-ів? писати extensions на js о_О?
58:51 очікування vs реальність
1:05:48 Як підтримує API і чи воно треба? (Про те як правильно покривати API тестами)
1:09:20 як функіонал є базовим для таких фреймворків і чи є він тут?
1:11:24 про тестування CRM систем і чому virtuoso тут теж програє
1:12:19 модель конструктора як альтернатива
1:14:18 альтернатива з cucumber
1:19:33 великі проблеми класних фіч virtuoso
1:19:46 про AI testing в codeceptJS
1:20:59 про дебагінг в playwright
1:21:28 сумнівна перевага використання людськоподібної мови
1:23:17 codeceptJS - недоліки дизайну для рефакторингу
1:40:43 скільки часу потрібно, щоб вивчитись і лідувати проект з нуля?
1:43:58 кейс однієї студентки
1:45:20 про важливу навичку в навчанні і як її качати
1:53:47 градація рівнів спеціаліста від джуна до ліда
1:55:47 чи можна і варто всіх залучати до автоматизації?
2:02:03 чому Яша не активний у соц мережах
2:03:39 чим Яша займається?
2:13:50 про мрію в автоматизації
13.03.202417:00
Го тестити virtuoso.qa на стрім https://youtube.com/live/UqiuIw9AsL0 !!!
25.11.202310:06
Ще 14го листопада мій хороший товариш та продакт менеджер (довоєнний бо з початку доброволець) оголошував збір з ціллю в 250к. За десяток днів, хлопцям ще не вистачає біля 70к на очі в небі. Давайте допоможемо чим зможемо 🎯
🔗Посилання на банку
https://send.monobank.ua/jar/7xUq6azYSD
💳Номер картки банки
5375411210427436
🔗Посилання на банку
https://send.monobank.ua/jar/7xUq6azYSD
💳Номер картки банки
5375411210427436
18.03.202413:31
Ми автоматизуємо тести не для тестувальників ✋🏻, а для розробників 🦾. Ціль не у тому щоб допомогти з мануальною рутиною тестувальникам на стадії тестування, а у тому щоб помогти розробникам не пропустити дефекти, які вони «тільки що наробили» і от от хочуть уже перевести таску в done чи ready for test... ну а далі «класичний пінг-понг» між тестерами і девами 🏓... Тут можна довго придиратись до формулювань, адже з якого це дива взагалі ділити на «це тестування» а це «ще не тестування». Так і є... Але тут трюк в акценті. Якщо трошки змінити кут зору, то можна почати бачити оптимізації там, де раніше вони були не очевидні. Якщо ми починаємо більше думати про розробників, максимально «ближче до них» впроваджувати автоматизацію і інтегрувати її саме у «життя девів», то починає виявлятись що навіть меншою кількістю покриття ми досягаємо більшого в плані якості. Деви тупо починають «менше робити багів».
І в цю ж тему відповідно до розгляду куча практик від розподілу покриття по піраміді до банального включання навіть end-to-end тестів у репу самої апки. Ясно що виключення є скрізь, але, можливо... і враховуючи принцип YAGNI - це «енд ту енд тести окремо від коду проекту є виключенням ніж навпаки». Раз уже наш клієнт - це деви, то чому б і тести не «тримати поближче до них»... Про от це «ближче до того де воно використовується» – ось ця гарна стаття https://kentcdodds.com/blog/colocation 😉 Цікавий термін co-location... Вперше почув) Зазвичай це cohesion-ом обзиваю, та й оригінально з появою React-у саме цей термін і використовули як селлінг поїнт його підходу «вью та логіка вью разом», але щось є у ко-локації - якось більш прямо говорить про що воно 😎
І в цю ж тему відповідно до розгляду куча практик від розподілу покриття по піраміді до банального включання навіть end-to-end тестів у репу самої апки. Ясно що виключення є скрізь, але, можливо... і враховуючи принцип YAGNI - це «енд ту енд тести окремо від коду проекту є виключенням ніж навпаки». Раз уже наш клієнт - це деви, то чому б і тести не «тримати поближче до них»... Про от це «ближче до того де воно використовується» – ось ця гарна стаття https://kentcdodds.com/blog/colocation 😉 Цікавий термін co-location... Вперше почув) Зазвичай це cohesion-ом обзиваю, та й оригінально з появою React-у саме цей термін і використовули як селлінг поїнт його підходу «вью та логіка вью разом», але щось є у ко-локації - якось більш прямо говорить про що воно 😎
13.03.202413:40
Нагадую що сьогодні о 19:00 тестимо virtuoso.qa 😉 Посилання на стрім прилетить сюди ж перед початком.
10.11.202313:39
Чи прям так playwright 🎭 швидше за SElenium ⚛️? 🤔
Ми 🎭 використовуємо на деяких проектах вже давно, але я так ніразу і недобігав реально зрівняти швидкість. І от – припекло🤡 А то Рома от останнім часом «кричить» що «селеніум тепер тільки для бабуїнів» (це моя дуууже вільно-перекручена інтерпретація сенсу, ги) а я якось для себе ще крапок над і не розставив... ну бо 🎭 тільки під web, бо API все ще формувався, до сих пір доволі не консистентний місцями, часом радикально стрибав у інший бік (слава богу що правильний – це я про page.locator замість усього іншого). І от я вже почав переживати що я зовсім не в тренді... Не солідно 🙂
Так от, ми тут поки дуже простенький End-to-End на TodoMVC апку запустили, типу всі види операцій по черзі проробити у сценарії. На 10тьох ранах (так, так, знаю що мало, але грець з ним) – Мінімальна різниця в часі – 11% відсотків усього! Опа опа, такий вже прям і швидший? 🙂 ... Це я так інтригу тримаю... Ну ок, таки є стрибки і аж до 64%. І середня різниця виходить – 35%, що вже не так і мало...
Але тут є ще один цікавий нюанс...
Зрівнювали ми не з чистим SElenium а саме з SelenideJS, тобто селенідоподібним врапером обмазаним зсередини розумними неявними очікуваннями а ззовні лінивими елементами – що самі по собі давлять на гальма поверх чистого селеніуму (все заради добра, стабільності тестів, і все таке, але зараз не про це), і якраз от ця різниця десь приблизно і лежить в залежності від ситуації між 25 і 75 відсотками (це я знаю бо тестив не раз всі свої селени/селеніди в порівнянні з селеніумом). Виходить цікавий висновок – саме в порівнянні з чистим селеніумом ймовірно не на так багато плейврайт і швидше 🤡 Але якщо порівнювати його з чимось типу селенідів що = селеніум + окрім усього + вбудовані очікування на кожен чих, то отримуємо вже щось типу 35% на користь плейврайту... І дуже може бути що якраз ці 35 відсотків і пов'язані з тим що плейрвайт більш ефективно саме "неявно чекає", адже саме в цьому вся фішка його движку, який побудований на набагато ефективніших з точки зору "комунікації" вебсокетах а не http як селеніум...
Тепер питання – чи дійсно того як чекає плейврайт – достатньо? чи настільки ж він стабільний з коробки як селеніди? І якщо так, чи можемо ми на боці селенідів таки зменшити відставання від 35% до чогось хоча б близького до спостереженого мінімуму в 11% у наших тестах...?
P.S.
Далі буде ще серія постів про плейврайт та його порівнянь з селенідами, включно по нюансам синтаксису, тому stay tuned 😉 Для тих хто любить спойлери – по нашим останнім зрівнянням – 🎭 хоч і не так красиво і консистентно але по суті дублює синтаксис селенідів, що означає що навіть врапер довкола плейврайту не особливо то вже зараз і потрібен... Хоча у мене руки все ще чухаються його доробити 🙂
Ми 🎭 використовуємо на деяких проектах вже давно, але я так ніразу і недобігав реально зрівняти швидкість. І от – припекло🤡 А то Рома от останнім часом «кричить» що «селеніум тепер тільки для бабуїнів» (це моя дуууже вільно-перекручена інтерпретація сенсу, ги) а я якось для себе ще крапок над і не розставив... ну бо 🎭 тільки під web, бо API все ще формувався, до сих пір доволі не консистентний місцями, часом радикально стрибав у інший бік (слава богу що правильний – це я про page.locator замість усього іншого). І от я вже почав переживати що я зовсім не в тренді... Не солідно 🙂
Так от, ми тут поки дуже простенький End-to-End на TodoMVC апку запустили, типу всі види операцій по черзі проробити у сценарії. На 10тьох ранах (так, так, знаю що мало, але грець з ним) – Мінімальна різниця в часі – 11% відсотків усього! Опа опа, такий вже прям і швидший? 🙂 ... Це я так інтригу тримаю... Ну ок, таки є стрибки і аж до 64%. І середня різниця виходить – 35%, що вже не так і мало...
Але тут є ще один цікавий нюанс...
Зрівнювали ми не з чистим SElenium а саме з SelenideJS, тобто селенідоподібним врапером обмазаним зсередини розумними неявними очікуваннями а ззовні лінивими елементами – що самі по собі давлять на гальма поверх чистого селеніуму (все заради добра, стабільності тестів, і все таке, але зараз не про це), і якраз от ця різниця десь приблизно і лежить в залежності від ситуації між 25 і 75 відсотками (це я знаю бо тестив не раз всі свої селени/селеніди в порівнянні з селеніумом). Виходить цікавий висновок – саме в порівнянні з чистим селеніумом ймовірно не на так багато плейврайт і швидше 🤡 Але якщо порівнювати його з чимось типу селенідів що = селеніум + окрім усього + вбудовані очікування на кожен чих, то отримуємо вже щось типу 35% на користь плейврайту... І дуже може бути що якраз ці 35 відсотків і пов'язані з тим що плейрвайт більш ефективно саме "неявно чекає", адже саме в цьому вся фішка його движку, який побудований на набагато ефективніших з точки зору "комунікації" вебсокетах а не http як селеніум...
Тепер питання – чи дійсно того як чекає плейврайт – достатньо? чи настільки ж він стабільний з коробки як селеніди? І якщо так, чи можемо ми на боці селенідів таки зменшити відставання від 35% до чогось хоча б близького до спостереженого мінімуму в 11% у наших тестах...?
P.S.
Далі буде ще серія постів про плейврайт та його порівнянь з селенідами, включно по нюансам синтаксису, тому stay tuned 😉 Для тих хто любить спойлери – по нашим останнім зрівнянням – 🎭 хоч і не так красиво і консистентно але по суті дублює синтаксис селенідів, що означає що навіть врапер довкола плейврайту не особливо то вже зараз і потрібен... Хоча у мене руки все ще чухаються його доробити 🙂
Көрсетілген 1 - 12 арасынан 12
Көбірек мүмкіндіктерді ашу үшін кіріңіз.