Тестирование ≠ QA
Open in Telegram
233
Subscribers
No data24 hours
No data7 days
No data30 days
Data loading in progress...
Similar Channels
No data
Any problems? Please refresh the page or contact our support manager.
Tags Cloud
No data
Any problems? Please refresh the page or contact our support manager.
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
November '23
November '23
+1
in 0 channels
October '230
in 1 channels
Get PRO
September '23
+4
in 0 channels
Get PRO
August '230
in 0 channels
Get PRO
July '230
in 0 channels
Get PRO
June '23
+1
in 0 channels
Get PRO
May '23
+5
in 0 channels
Get PRO
April '23
+4
in 0 channels
Get PRO
March '23
+2
in 0 channels
Get PRO
February '23
+8
in 0 channels
Get PRO
January '23
+1
in 0 channels
Get PRO
December '22
+3
in 0 channels
Get PRO
November '22
+7
in 0 channels
Get PRO
October '22
+9
in 0 channels
Get PRO
September '22
+59
in 0 channels
Get PRO
August '22
+4
in 0 channels
Get PRO
July '22
+206
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 13 November | 0 | |||
| 12 November | 0 | |||
| 11 November | 0 | |||
| 10 November | 0 | |||
| 09 November | 0 | |||
| 08 November | 0 | |||
| 07 November | 0 | |||
| 06 November | 0 | |||
| 05 November | 0 | |||
| 04 November | 0 | |||
| 03 November | 0 | |||
| 02 November | +1 | |||
| 01 November | 0 |
Channel Posts
Про повышение
TLDR: не получилось.
Далее подробнее.
Писать о неудачах в целом сложнее, но считаю, что это важно для обмена опытом.
Зимой я поставил цель достичь следующего уровня по своей ветке IC (Individual Contributor). Помимо какой-то морковки в виде формальной цели, в этом был и чисто финансовый интерес — благодаря наслоению налоговых факторов, связанных с начислением акций от работы, мы полностью потеряли весьма существенную ежемесячную сумму детских денег от 🇨🇦.
В Unity в целом градация для сеньоров такая:
— IC 6: твердый сеньор
— IC 7: супер сеньор в своей команде, способный в одиночку делать задачи проекта с высоким качеством
— IC 8: staff в команде или расшаренный между командами, еще более опытный чел, способный курировать несколько проектов и стеков
— IC 9: principal, архитектор
И здесь мы подходим к понятию сеньорства как такового. Разные люди рассматривают эти уровни по разному, и возможно, это стоит выделить в отдельный пост, но мое понимание таково: если в вашей команде люди сильнее вас, нужно бежать в два раза быстрее, чтобы получить повышение вне зависимости от внутреннего ощущения своей сеньорности.
В моем случае из 11 лет опыта я силен в собственно в качестве, тестировании, менеджменте и процессах. В рамках этого можно замахнуться и на большее. В SDET же, пожалуй, на высоком уровне могу в E2E и API автотесты. Что в совокупности достаточно для IC 6, а на 7 нужно больше и лучше.
Это у меня не получилось, и вот почему.
Как я уже писал, ожидания команды из-за общего уровня весьма высоки, и по факту должен стать почти таким же скилловым разработчиком, но с упором на качество и тестирование. В нашем проекте не так много ручного тестирования, так как при нескольких релизах в день это не масштабируется.
В этих условиях я в свою очередь пытался развить оба направления: больше влиять на культуру и процессы, разрабатывать общую стратегию, добавлять фреймворки, писать и менторить автотесты. В свободное же ночное время проходил курсы по разработке, подтягивая слабые места.
Хотя нужно было всеми силами тащить программирование и девопс. Чем я и планирую заниматься теперь.
| 2 | Апдейт: у Unity новый СЕО, и у меня появилась надежда, что:
а) топам пока будет не до возврата в офис
б) нам коллективно можно будет попробовать давить на Best Ideas Win, чтобы найти компромисс в условиях, когда команды максимально удалены друг от друга и уйти от совкового подхода, когда у всех уравниловка.
Почему надежда: новый СЕО работал в Redhat, и там он (после стандартного кровавого корпората) столкнулся с тем, что люди на местах могут предлагать лучшие решения. Об этом его TED talk, очень рекомендую посмотреть, там смешно. | 0 |
| 3 | Тестовое задание на автоматизацию #1
Для начала пояснения: некоторые компании не хотят шарить свои тестовые, поэтому я не буду употреблять названия. Хоть и шанс кому-то из читателей податься в ту же контору с тем же заданием равен нулю, честно говоря. И сами тесты будут изменены, но суть и выбранная сложность останутся.
Предлагаю желающим попрактиковать свои навыки присоединяться. Тем, кто прошел мой курс, очень рекомендую освежить знания на реальных задачках.
Давайте так, кто захочет решить:
- на выбор Cypress или Playwright
- код кидать в комментарии в виде ссылки на GitHub Gist или лучше репозиторий, откуда можно скачать и запустить проект (если совсем стеснительно, можно в личку)
С меня ревью и предложения по улучшению. Вам это поможет набить руку в оформлении тестовых и в итоге получить некое портфолио, если еще не. Ставьте лайки, зовите друзей, кому актуально.
Тест 1
- Открыть https://www.cypress.io
- Кликнуть на 'npm install cypress' CTA
- В попапе кликнуть на 'npm install cypress' CTA
Убедиться, что текст в буфере обмена равен npm install cypress --save-dev
Тест 2
- Открыть https://www.cypress.io
- Проскроллить до текста "Loved by OSS" и убедиться, что он отображается
- Вывести в лог число загрузок за неделю без "М+"
Напомню, что цель тестовых - не просто решить (обычно не супер сложную) задачку, а и продемонстрировать уровень, на который вы идете. Поэтому нет предела совершенству, можно накручивать сложность, если видите, что в этом есть смысл. | 0 |
| 4 | Something new
TLDR: Начинаю искать новую работу
С сентября нас, как и многих в этом году, выгнали в офисы на 3 дня в неделю. Я понимаю преимущества совместной работы, когда вы можете вместе тусить, парно программировать или разбираться в сложной хренотени.
Проблема в том, что за ковид глобальные компании набирали таланты, а не команды около офисов. В моей конкретной ситуации в Монреале есть только один staff engineer, с которым мы весьма редко работаем над чем-то вместе. А добираться надо в лучшем случае от 1.5 часов в одну сторону с кучей пересадок, то есть, больше 3 часов в день тратить практически без цели.
Самое обидное, что это первый за карьеру проект, где мне нравится всё — матерая команда, современные технологии, идеи по развитию продукта, бесконечные возможности для развития хард скиллов в автоматизации, ну и компенсация в целом адекватна рынку.
Будет непросто. В первую очередь потому, что почти все большие конторы (с бюджетами на зарплаты) перешли на гибрид, и на рынке достаточно мало вакансий и много желающих, что дает нам типичную ситуацию рынка, когда работодатели могут выбирать и снижать ожидаемые зарплаты.
На днях сгоряча почти нашел работу — в одном стартапе успешно прошел интервью, но замешкался, и они взяли другого человека. Покопавшись на линкеде, стало понятно, что всё не так просто, как казалось на берегу.
Возможно, что-то изменится в моем восприятии или в самой компании, и я останусь, но пока буду искать.
Если кому-то интересно узнать, как будут проходить интервью, напишите в комментариях. | 0 |
| 5 |  А напишите в комментариях, вы часто/постоянно тестируете в таком стиле? Если да, как часто находите критичное? | 0 |
| 6 | Всех причастных с undefined! | 0 |
| 7 | GitHub Actions: как подменить параметры в файле перед отправкой на другой сервер
Думаю, может быть полезно скидывать какие-то штуки/находки из повседневной работы в формате "вопрос-решение" для расширения кругозора.
Задача
Ранее тесты нагрузки запускались ручками: загружались файлы на сервер, руками же копировался запрос запуска тестов на Swagger странице. Так как тесты стали запускаться чаще, нужно было это все автоматизировать из GitHub Actions (GHA), чтобы в одном месте разработчики могли задавать параметры и для самого JMeter, и для нашего внутреннего облачного сервиса. Например, хочу запустить тесты на 500 пользователей из Штатов и Европы на трех машинах на час.
Файлы тестов и конфигурации облаков копируются напрямую из гита, поэтому нужно перезаписать дефолтные значения конфигов на то, что введено в формах GHA.
Решение
Вместо actions вида replace string, ребята посоветовали использовать sed редактор, который на лету подменяет нужные строчки (помимо всего прочего полезного).
Например, есть yaml файл, который содержит конфигурацию вида:
modules:
jmeter:
properties:
USER_COUNT: ${USER_COUNT}
DURATION_IN_SECONDS: ${DURATION}
Тогда шаг GHA будет выглядеть как-то так:
- name: Set execution variables
run: |
cd <your file path>
sed -e 's/${THREAD_COUNT}/${{inputs.number-of-threads}}/g' -e 's/${DURATION}/${{ inputs.test-duration }}/g' filename.yaml > filename-updated.yaml
Где ${USER_COUNT} и ${DURATION} это строчки файла, которые надо заменить (доллар и скобки для наглядности, что это значение, это может быть любой текст), а ${{inputs.number-of-threads}} и ${{ inputs.test-duration }} это значения соответствующих полей, введенные в форме. После подмены можно продолжить с отправкой файлов. | 0 |
| 8 | Публичный собес джуна ручного тестировщика
Достаточно стандартные вопросы и в целом адекватные ответы. Можно кинуть тем, кто входит в тестирование, чтобы им примерно понимать, как проходит процесс, какой сложности вопросы и собственно что нужно понимать (не бездумно заучить) для того, чтобы претендовать на эту позицию.
От себя добавлю, отрадно видеть, что в русскоязычном пространстве принято на начальном уровне уже знать основы. Опыт многих встреченных ребят из Северной Америки меня нередко удручает.
https://youtu.be/F0R8UfliZnU?si=1XcmH7gK631Bf-ZL | 0 |
| 9 | Итоги вебинара в альпине. О чем молчат программисты
На днях я проводил вебинар для программистов, лидов и тех директоров для клиентов корпоративных библиотек альпины. Было около 100 человек и мы довольно плотно пообщались полтора часа. Говорили о всяких техниках, которые позволяют уменьшить time to market способами, которые либо не очевидны, либо идут в разрез с общепринятыми концепциями. Здесь я поделюсь теми концепциями, которые вызывали наибольший интерес и дискуссию.
Большая часть того, что описывалась в докладе, базируется на том как устроен инжиниринг в букинге https://apptractor.ru/develop/kak-ustroen-inzhiniring-v-booking-com.html Главная идея там, это то, что мы двигаемся быстро, но по пути можем что-то ломать. Остальное придется прочитать по ссылке выше 🙂
И так из важного. Если построить процесс разработки определенным образом, то мы можем значительно ускориться за счет частичного или полного отказа от тестировщиков, стейджинга, синхронных код ревью и деплоев по расписанию после демо дня.
Да из каждого пункта есть исключения, например в мобильной разработке тестировщики нужны из-за особенностей релизов, но, в целом, их можно применить почти везде получив значительное ускорение процесса. Например мы прошли этот путь на Хекслете, когда году в 2016 мы убрали стейджинг и не случилось ничего страшного, а стало сильно проще. Быстрее цикл релиза, меньше поддержки инфраструктуры, меньше завязки на то, что кто то проверит за меня, а значит я могу забить на проверку своего кода.
Если вам нужно больше доказательств, то пожалуйста https://news.ycombinator.com/item?id=30899362 в фейсбуке стейджинг не используется. https://refactoring.fm/p/do-you-need-staging большая и классная статья про это же. Вообще если погуглитть, окажется что подобных статей и примеров отказа от стейджинга очень много.
В следующих постах я буду продолжать развивать эту тему, до тех пор пока мы не пройдемся по всему, что было в докладе.
А у вас есть стейджинг? | 0 |
| 10 | Основатель Хекслета, Кирилл Мокевнин, завел канал, и в этом посте (как и всегда, впрочем) ратует за культуру, в которой тестировщики становятся ненужны | 0 |
| 11 | Мем мемом, но если присмотреться, бизнес действительно фокусируется на самых ценных сотрудниках в случае экономической нестабильности.
При наличии достаточно скилловой команды разработчиков, они сами могут заменить и QA, и всяких проджектов с другими менеджерами. А наоборот, как вы понимаете, не работает — вышеназванные «паразитируют» на работе разрабов, и обойтись без них не могут.
Понятно, что все зависит от нюансов проекта и самих людей, но посыл в том, чтобы в очередной раз подумать, насколько ваши текущие умения добавляют ценности компании. И не стоит ли начать что-то киллерфичное прокачивать, пока не придет «HR с ножницами». | 0 |
| 12 | Selectors: best practices
Главная проблема с автогенерируемыми селекторами для e2e тестов в том, что часто там получается хренотень вида:
cy.get(':nth-child(1) > .card > .card-block > .card-title > .hrefch')
А когда подряд идут команды с подобными монстрами, читабельность тестов падает катастрофически:
cy.get('#page-wrapper > div > div.col-lg-1 > button').click()
cy.get ('#orderModal > .modal-dialog > .modal-content > .modal-footer > .btn-primary').click()
В этом случае никакие комментарии уже не помогут, слишком большая когнитивная нагрузка. Да, такое можно спрятать за абстракцией по типу любимого Page Object, но это не уберегает от изначальной хрупкости CSS селекторов - такие длинные могут перестать работать после какого-то очередного рефакторинга. Еще хуже, когда фреймворк типа React генерирует новые имена классов после каждой сборки.
В целом, это все не есть гуд, и нам нужен способ лучше.
Что делать
Кратко: в проектах, к которым у вас есть доступ, Cypress рекомендует использовать data атрибуты к тем HTML элементам, с которыми вы будете взаимодействовать в тестах. Это на данный момент самый надежный способ получить то, что нам нужно: однозначный, по желанию краткий и устойчивый к рефакторингу кода селектор.
Если вы не знаете, как это делать, попросите разработчиков научить, чтобы не зависеть от них. Это не так сложно.
И тогда ваш код теста сведется к такому:
cy.get('[data-test="submit"]').click()
или даже
cy.getBySel('submit').click()
где getBysel это просто обертка для обычного cy.get:
cy.get(`[data-test='${selector}']`, ...args))
Если вы мучаетесь с CSS селекторами, покажите вот эту ссылку вашим разработчикам: docs.cypress.io/guides/references/best-practices#How-It-Works
Там подробно разбирается, почему data атрибуты это лучший выбор.
---
Testing Library
Но стоит так же отметить, что Cypress сам использует и рекомендует Testing Library, примеры кода:
cy.get('form')
.findByRole('button', {name: /Button Text/i})
cy.findByLabelText(/Label text/i).should('exist')
Могу сказать, что те фронты, что пишут тесты на компоненты, могут быть знакомы именно с этим способом, поэтому это вторая хорошая опция, которая к тому же ближе к DX самих разработчиков. Вот ссылка на примеры: testing-library.com/docs/cypress-testing-library/intro/#examples
---
Все описанное выше лучше смотреть с картинками и пояснениями: telegra.ph/Selectors-best-practices | 0 |
| 13 | Test replays в Cypress
Пока писал предыдущий пост, СЕО Cypress анонсировал скорое появление test replays в Cypress Cloud.
Это хорошо, так как на фоне Replay.io и Playwright Cypress начинал проигрывать в отладке падающих CI тестов, имея для анализа только видео и скриншоты. А этого явно недостаточно в более сложных случаях, которые встречаются не так уж и редко.
То, что анонсировано в replays, пока больше походит на привычный open mode, где доступны базово нужные фичи:
- Time travel
- DOM inspection
- Network requests
- Console logs
- Retries
Пока нет продвинутых фич Replay.io с возможностью копаться в React Dev Tools и дебажить приложение прямо в реплее, но это могло бы быть логичным развитием. Также указано, что это будет доступно только в Chromium браузерах, непонятно, появится ли когда-то поддержка Firefox и/или Safari.
Понятно, почему они включили эту фичу в платный сервис dashboard. Бизнес-модель компании у многих вызывала вопросы, так как сервис аналитики запусков тестов нужен далеко не всем. Поэтому они стараются перетянуть бесплатных пользователей на какие-то крутые плюшки, и replays в этом поможет.
В то же время Playwright предоставляет вообще все бесплатно, но при этом у него нет и этих собственных модных фич типа умной аналитики на основе данных прошлых запусков, умной же параллелизации на CI и не рубленного топором дизайна (соряяян 😁️️️️). Очевидно, что при большем фокусе Cypress на их платном продукте, разработчики без бюджета и без нужды на подобные фичи, пожалуй, будут всё более склоняться к Playwright.
Но тем интереснее и наблюдать за развитием мелкого кровавого энтерпрайзика с Cypress и его платным аддоном и полностью опенсорсным продуктом от гигантского энтерпрайзища. Самое главное, что есть выбор. Напомню, фреймворки на данный момент борются не друг с другом, а за те команды, что не пишут тесты вообще, и этих ребят всё еще очень много.
Полная запись вебинара: https://www.youtube.com/watch?v=hX9Br8QSYgc | 0 |
| 14 | Порекомендую вдогонку видеообзор Replay.io в связке с Cypress.
Filip наглядно показывает на примере онлайн магазина, как он дебажит тест, находит причину его хрупкости и вместо адаптации теста, фиксит само приложение:
https://youtu.be/4wL8Qi9vjho | 0 |
| 15 | Тренд: куда (уже год) движется дебаггинг e2e-тестов и hard-to-reproduce багов
Я писал о том, что часто главная проблема с E2E тестами не в самом написании, ведь это по большому счету эдакий макрос, сложность начинается в поддержке. Согласен с мнением, что не так важно, на сколько (нано)секунд один фреймворк быстрее другого, важнее то, как быстро вы сможете отладить и исправить тест. Именно дебаггинг flaky тестов отнимает больше всего времени, в особенности, когда эта хрупкость происходит только на CI. Так как время разработчиков всегда дороже CI-ного железа, поэтому именно об этом стоит думать в первую очередь.
Приверженцы Playwright справедливо указывают на добавленный Trace Viewer, где можно скачать трейс упавшего теста и копаться в Dev Tools и командах теста, откатываясь на нужный момент. Это в принципе та же идея (которая и является общим трендом) но лучше и работающая с другими популярными фреймворками.
Replay.io
Что это такое: сервис, предоставляющий chromium браузер, который можно скачать, прогнать тест руками или подключить к вашему тестовому фреймворку.
Плагины для всех популярных инструментов:
- Cypress
- Playwright
- Puppeteer
- WebdriverIO
- Jest
https://docs.replay.io/test-suites/test-runners
Где это больше всего нужно: hard-to-reproduce bugs, которые часто закрываются с пометкой Cannot Reproduce, а также автотесты, которые в свою очередь любят падать исключительно на CI.
Как работает: вы воспроизводите баг, сервис сохраняет эту сессию со всеми приблудами для отладки, а разработчики вместо скриншотов и видео получают супер способности для его дебага и фикса. То же применимо в случаях flaky тестов на CI.
Что сохраняется в реплее: видео, исходный код приложения, DOM снэпшоты, timetravel-enabled devtools, которые позволяют ретроактивно добавлять логи в нужные фичи приложения. Туда же ручные тестеры могут добавить комментарии с пояснениями нюансов.
Отличие от Trace Viewer: Я зарегистрировался, и там приходит автоматическое письмо а-ля "Привет, я тут самый главный СЕО, все пишите, на всё отвечу". Пользуясь случаем, спросил, в чем их отличие от Playwright, и вот, что они ответили: "You can think of Replay DevTools as Chrome DevTools with replay super powers. Replay's DevTools are similar to the Trace Viewer, but much more. For example, you can add retroactive print statements that log expressions to the console".
Самая главная фича для разработчиков: они видят не только то, что случилось, но найти причину, почему это происходит. Replay.io поддерживает React с его state manager типа Jotai or Redux, что позволяет заглянуть внутрь component’s state и посмотреть на его изменения на протяжении всего реплея.
Предлагаю поиграться тем, кто еще не пробовал, для одиночек сервис навсегда бесплатный. | 0 |
| 16 | Как найти элементы и генерация шагов теста
Когда уже есть шаги теста в уме или в написанном виде (см предыдущий пост), встает вопрос, что делать дальше. Если с ручным прокликиванием все понятно: открыл браузер и пыщь-пыщь по кнопочкам, то в случае автотестов фреймворк как-то должен понять, на что именно кликнуть или куда там вводить текст. И так как нет одного правильного ответа (один и тот же элемент может быть найден кучей способов), селекторы по факту это первое "препятствие", где, по недавнему опыту, начинающие могут буксовать.
Поэтому сделаем первый подход к ним: разберем, что это такое, какие есть способы найти уникальный, включая те, что делают работу за нас. Не пугайтесь, есть способы начать без траты часов на изучение HMTL, DOM, CSS/Xpath селекторов.
Способы найти элемент из данного уроке:
- Руками в Dev Tools
- Cypress Selector Playground
- Cypress Studio
- Chrome Dev Tools + Cypress extension
Последние два - record&play (фанаты Selenium IDE ликуют). Код, который подобные тулзы генерируют, все равно нуждается в допиливании, зато на первых порах позволяет пропустить возможное раздражение от селекторов, тем более, что в следующем уроке описывается предпочтительный способ работы с ними, если у вас есть доступ к исходному коду.
В рамках обычного поста в канале неудобно пошагово объяснять, поэтому читайте руководство с картинками и кучей пояснений здесь: урок №4. | 0 |
| 17 | На что обращать внимание при подготовке сценариев e2e тестов
Это тема урока №3.
В начале пути даже опытные ручные тестировщики делают ошибки при составлении шагов теста, которые затем будут автоматизироваться. Поэтому здесь я разбираю нюансы e2e и объясняю, на что ориентироваться, чтобы получить кейс, который покрывает нужную фичу.
Хорошая новость: e2e мало чем отличаются от ручных. Это всего лишь последовательные шаги какого-то тест-кейса и одна или несколько проверок на то, что мы действительно получили нужный результат.
Разумеется, есть нюансы. Из-за того, что этот вид тестов является самым тяжелым, медленным и одновременно хрупким, рабочая практика в случае web-проектов – разделять усилия на:
- Unit (индивидуальные функции)
- Integration/Component (отдельные UI компоненты: header, footer, buttons)
- E2E (приближенные к действиям пользователей сценарии)
- Отдельно упомяну API (отдельные запросы-ответы/сценарии с логикой на задеплоенном окружении), потому что они тоже могут быть в этой зоне ответственности
Помимо всех минусов, у e2e есть самый главный плюс – они тестируют всю систему в сборе, и это максимально близко к поведению пользователя. Да, можно на нижних уровнях замокать все, что движется, но излишний мокинг приводит к мемам по типу вот этого. Поэтому осознанный подход к e2e, когда они пишутся там, где есть смысл – то, что нам нужно. Далее про нюансы, которые нужно учитывать.
E2E тестами стараются покрыть самые важные сценарии
Как понять, что является важным? Ориентируйтесь на revenue loss, то есть, если какой-то конкретный сценарий перестал работать, и бизнес явно теряет или недополучает деньги – это первый кандидат на автоматизацию, так как нам важно как можно скорее знать, что это перестало работать на каком-то этапе разработки. Остальные тесты приоритезируются по степени удаления от этой логики (да, есть и другие критерии, но этот самый нужный в рамках данных уроков).
На основе замеченных ошибок у студентов даю советы, о чем нужно помнить при составлении тестов.
Советы:
1. В первую очередь думайте про позитивные кейсы
2. Не забывайте, что тест-кейс должен быть написан так, чтобы любой тестировщик без знания вашего домена мог прийти и сделать его без дополнительных пояснений. Это позволяет не упускать детали перед началом написания кода
3. Помните о том, что тест должен быть независимым: по умолчанию браузер для каждого теста будет запускаться с чистого листа, поэтому несохраняемые изменения, сделанные предыдущим тестом (добавление товара в корзину анонимным пользователем), не будут применены в следующем
4. В то же время есть изменения, которые без ресета остаются в системе, поэтому второй раз этот же тест не пройдет с теми же данными. Пример: регистрация пользователя. Говоря профессиональным языком: нужно убедиться, что тест детерминирован
5. Пройдите шаги теста руками, вас могут ждать сюрпризы | 0 |
| 18 | Начинаю разбирать уроки и попутно объясняю, почему они именно в таком порядке
1. Первый тест
2. Запуск тестов на CI (GitHub Actions)
Зачем: с этими двумя я хочу запрыгнуть с места в карьер и с помощью копипасты с пояснениями дать ученикам возможность заиметь что-то работающее с первых же шагов.
Первый тест презентует тестовый сайт, раскрывает общий синтаксис Mocha (describe, it) и пошагово разбирает сам базовый тест.
describe('Имя Для Группы Тестов Вашей Фичи', () => {
it('Имя Первого Теста', () => {
какие-то шаги
})
it('Имя Второго Теста', () => {
другие шаги
})
})
Запуск на CI мне нужен для того, чтобы сразу акцентировать внимание на хрупкости E2E тестов. Самый большой бич этого типа разработки — когда тест проходит локально, и иногда падает на CI. В моей собственной практике и с нашим выбранным тестовым сайтом это случалось неоднократно.
name: E2E Tests
on:
push:
jobs:
run-cypress-tests:
runs-on: [ubuntu-latest]
container: cypress/included:12.11.0
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Cypress run
uses: cypress-io/github-action@v5.6.1
- name: Archive Test Report (If Fails)
if: ${{ failure() }}
uses: actions/upload-artifact@v3
with:
name: test-report
path: |
./cypress/screenshots/
./cypress/videos/
Приведенный минимальный (всего 20 строк) workflow файл делает все, что нужно: запускает тесты на каждый push в репозиторий, Cypress action делает всю грязную работу типа зависимостей и кэширования, запускает тесты, постит мини-репорт по завершению и, если тест падает, сохраняет скриншоты и видео падения для дальнейшего изучения. | 0 |
| 19 | Все уроки курса "Cypress scouts: E2E automation basics from scratch"
Целевая аудитория
Тестировщики, которые пытались влезть в E2E автоматизацию самостоятельно и бессистемно, но не получилось.
Что вы получите по итогу
С минимальным необходимым знанием Javascript у вас будет репозиторий с собственными (не шаблонными) тестами на сайт с заказом товаров.
Главный плюс
Вы на практике будете бороться с самой главной болезнью E2E тестов - их хрупкостью.
Что еще включено:
- Тесты будут запускаться на CI (GitHub Actions)
- Несколько способов, как находить селекторы элементов
- 3 способа правильного ожидания изменений на странице
- Как делать проверки
- Как эффективно отлаживать тесты
- Best practices, применимые в любом фреймворке
Не знаю, отнести ли следующий эпитет из отзывов к плюсам - "залихватский язык"😜 Я старался живым, не канцелярско-академическим, языком описывать сложные моменты, поэтому если вам заходит стиль этого канала и/или моего канадского, должен зайти и курс.
Как я писал ранее, уроки плавно усложняются по мере продвижения от "Just Do It" до "Такие проблемы в целом решаются вот так, держи пример и документацию, дальше сам, я в тебя верю". В некоторых уроках я ссылаюсь на свой практический опыт разработки E2E тестов и на основе их даю варианты решения того или иного затыка.
Предусловия
1. Минимальный JavaScript
2. Настройка окружения
3. Git и установка Cypress
Список уроков
1. Первый тест
2. Запуск тестов на CI (GitHub Actions)
3. Сценарии для e2e тестов
4. Как найти элементы и генерация шагов теста
5. Selectors: best practices
6. Как делать проверки
7. Как отлаживать код тестов
8. Cypress: best practices
9. Custom commands и utility функции
10. Как правильно ожидать нужного состояния приложения
Для справки: при работе в группе и со мной в качестве ментора это заняло ~2 месяца.
Я хорошо представляю, что примерно 0 человек будут самостоятельно его проходить. Следующие группы будут, но попозже. Мне же это нужно сейчас, чтобы в одном посте складировать все наработки, и в дальнейшем по важным и трудным для студентов пунктам автоматизации пройтись отдельно. Тем самым, хочу для всех проговорить нюансы, на которых некоторые ребята буксуют. | 0 |
| 20 | Курс по автоматизации тестирования: первые впечатления
Напомню, я собрал группу людей под знаменами «я 10 раз сам пробовал, но так и не вошел в автоматизацию тестирования», с которыми провел 2 плотно-потных месяца, где, идя от простого к сложному, мы получили результат, и об этом далее.
Я хотел проверить, смогу ли только текстом объяснить сложные для начинающих вещи простым языком, и получится ли менторить группу людей с разными уровнями полностью удаленно. И да, всё — бесплатно.
Считаю, что для первого раза получилось неплохо, и этот новый скилл (и получившийся курс) буду переиспользовать. Однако, неудивительно, что это отнимает кучу сил и энергии, поэтому на другие каналы и хобби времени вообще не оставалось.
Отзыв после прохождения
«Давно мечтала вкатиться в автоматизацию и постоянно этому что-то мешало (работа на "галере" с максимальной нагрузкой, быт), всякий раз начинала разбираться и забрасывала а тут — этот курс: быстро, доходчиво, приятные формулировки и компания. То, что мне было нужно. Теперь понятно, куда копать дальше, осталось добыть проект :)
/ Не ожидала, что E2E тесты могут быть такими хрупкими |
Еще понравился опыт работы в группе - когда ты не один сталкиваешься с проблемами, читаешь решения остальных участников».
——
Этот фидбек — то, к чему я стремился: помочь людям, которые пробовали автотесты и отчаялись. Причем, я 💯 убедился в том, что таким нужен человек, который быстро сможет: помочь советом в случае затыка и объяснить почему и зачем мы делаем то или иное. В самообразовании почти всегда наступает момент, когда ты не смог справиться с непонятной задачей, забыл, забил и бросил. Поэтому стайная работа (с помощью ментора) над одним проектом, но с уникальными решениями у каждого ученика — пожалуй, лучший способ для такой передачи знаний.
Для этого вместо нудной теории в самом начале были уроки в стиле "бери и делай": заведи репозиторий, установи Cypress, скопируй первый тест и запили базовый CI на GitHub Actions.
Мне кажется, критически важно сделать что-то, получить первый результат и уже далее двигаться в глубину. Не становясь сначала сеньором в программировании, не влезая в Page Objects и прочие паттерны, но мотивируя себя за счет наглядных и постепенных итераций.
В общем, мне зашло, есть идеи на продвинутый курс со всякими прикольными штуками, но для этого нужно время.
А свои наработки по UI тестам из данного базового я буду постепенно выкладывать в канале для всех, зовите друзей 🙃 | 0 |
