vas3k.club
vas3k.club copied to clipboard
vas3k
Фича: E2E тесты
Хочу покрыть базовые сценарии E2E тестами, которые будут открывать браузер и что то в нем тыкать Это ишью завел чтобы обсудить, какими технологиями это начать делать и заасайнить его на себя Дискач:
Короче, предлагаю заюзать что-нибудь в стиле feature-файлов в gherkin нотации (cucumber / specflow) Ну и инструмент, которым по браузеру тыкать тоже надо выбрать
Вот, как мне кажется, самые ок варианты:
| Язык | Gherkin имплементация | Чем тыкать в браузере |
|---|---|---|
| python | behave | selenium |
| js | cucumberjs | webdriverio |
| java | cucumber | selenide |
Давайте выберем из этого? Можете предложить своё)
Ну, и еще - чтобы оно всё не тормозило и соответствовало пирамиде тестирования - E2E тестами надо покрыть только самые базовые сценарии - их должно быть мало)
Добавлю cypress (https://www.cypress.io). Сам не использовал, но пишут (вот тут например хорошо объяснено https://blog.logrocket.com/cypress-io-the-selenium-killer/), что гораздо удобнее Selenium'а. Язык там JavaScript.
Я бы с удовольствием присоединился к покрытию тестами, ну или хотя бы посмотрел на результат - очень хочется посмотреть как он в деле и сравнить с Python + Selenium.
В статье написано, что самое главное в чем cypress выигрывает у selenium - это время выполнения тестов. Это ошибочное утверждение, потому что проблемы возникают:
- в синхронизации приложения и тестов - обычно когда пишут тесты, то проблемы решают внутри тестов, хотя нужно копать с двух сторон
- в несоблюдении пирамиды - покрывают разные случаи e2e тестами, когда надо написать юниты / api
Кроме этого все равно будем подготавливать данные в датабазе / запускать эмуляторы
На этом этапе становится понятно, что какой бы инструмент не выбрали - все равно проблемы будут не в инструментах а в подходе
Энивей, тут нужен автор или другой человек, который принимает решение)
@FrameBassman поправлю: в статье речь идет не о времени выполнения, а о тайминге (т.е. синхронизации), как об основном преимуществе cypress:
The problems with selenium can be expressed in one word, timing.
То есть большая проблема в селениуеме - это флакирующие тесты. Когда у тебя тест пытается взять значение элемента, который еще не отписывался/не подгрузился/не обновился. И от этого рандомно падает или не падает.
И вторая проблема, которая призвана решить первую - это необходимость писать бойлерплейты для синхронизации этих самых элементов: всякие wait.until(conditions.<...>) или sleep(...).
Предлагаю в качестве "чем тыкать в браузере" заюзать https://github.com/microsoft/playwright. Насколько я понимаю это топовая штука сейчас.
Еще как альтернатива (один фиг у нас монополия в браузерах) — просто взять папеттер. Эту штуку пишут разрабы девтулзов хрома и она отлично работает.
@FrameBassman честно говоря, пока никак :) Пока нет фронтенд-боярина, который будет владеть и повелевать этими тестами, для меня это будет скорее обузой и я их просто выпилю через полгода красного мастера.
Но на позапрошлой работе у нас был cypress.io и было прикольно
@vas3k не, падажжи - не фронтенд-боярин должен e2e тестами владеть - они же всё приложение будут тестить Так что ими должны владеть все разработчики (но на самом деле я бы хотел ими владеть)
По поводу красного мастера - да, вы правы - их действительно сложно сделать красиво и чтоб они не мигали Но у меня есть идея как это сделать - и чтобы это реально приносило business-value - защищало мастер от автодеплоя приложухи, которая даже не взлетает - а это реально, если иногда хочешь сделать ПР с телефона, чтобы фиксануть опечаточку или попробовать какую нить гениальную идею - и самое главное - чтобы они не запускались минуты/часы/бесконечность времени
Короче, хочу сделать базовую имплементацию и попробовать помейнтейнить её например полгодика)
Вы в любое время сможете её выкинуть, если она будет не устраивать dev-тиму)
@vas3k ну так че, можно мы обсудим какими технологиями нам норм и сделаем ПР, в котором будет какая то базовая имплементация, которая всех устраивает (по времени и устойчивости?)
Я все еще не понимаю кто это будет поддерживать. Без ответа на этот вопрос я не вижу смысла иметь это в мастере. Хочешь попрактиковаться — сделай в отдельной бранче
Нене, попрактиковаться я и в собственной репе могу)
Давай проясним про "поддерживать" - что ты под этим понимаешь? К сожалению, каждый раз когда меняется функциональность - надо менять и тесты. На сколько я понимаю сейчас так и происходит: чувак, который поменял логику на бэке - меняет тесты на бэке; тот кто поменял логику на фронте - фиксит тесты на фронте (фронтовых тестов вроде нет, на скока я понимаю))
Короче, предлагаю тогда ишью закрыть @vas3k можешь еще раз четко сформулировать - не будем делать, потому что непонятно кто будет поддерживать, так? Я правильно понимаю, что ответ "я буду поддерживать" тебя не устраивает?
Еще я подумал, что многие могут путать UI и e2e тесты
Я же предлагаю запилить именно e2e тесты
UI тесты - это когда мокаем бэк и проверяем только фронт (в контексте этого ишью)
Думаю, такое можно было бы иметь в самых критических местах. Буквально одном-двух типа отправки комментов и оплаты. Да и то не понимаю как протестить оплату. То есть остается совсем узкий набор важных кейсов.
Во всех остальных случаях тесты будут лишь мешать развиваться. Никто не будет знать как их править, люди начнут забивать и бояться вносить полезные изменения.
Сейчас наша цель развиваться, а не охранять написанное. Move fast, break things, вот это вот всё. E2E тесты надо писать когда ты интерпрайз на 5000 человек. Нам я не понимаю зачем они пока.
Я абсолютно согласен - давайте напишем пару тестов, которые протестят оплату?
Тогда это намного проще будет сделать на уже имеющихся тестах в джанги, там даже есть что-то подобное :)
Хотя я все равно не представляю как написать такие тесты, чтобы быть 100% защищенным от опечатки в productID ошибки или обновления версии Stripe SDK.