Хорошая статья. Особенно отлично описаны mock, stub, fake. Сколько видел сломанных копий на эту тему. Для определения require и assert есть установившаяся в тестировании терминология: soft assert - проверяет результат и разрешает продолжение теста, hard assert проверяет результат и останавливает тест в случае фейла.
Да должен. Он не должен это уметь делать. Но знать разницу между двумя словами и разницу в стоимости и применимости для его проекта знать обязан. Контейнеризация дешевле в использовании, как по эксплуатации, так и банально по стоимости у облаков. Но, не все проекты можно делать на ней.
А вот это вообще root cause 90% провалом на проектах. Когда хотят "скраежопить", абсолютно не понимая чем это обернется. Не хотим держать свои сервера, CapEx - зло, переходим на облака, мы любим OpEx. И по налогам приятнее и денег сразу столько не нужно. А потом прибегает менеджер. Ой, что-то там такой счёт выставили из облаков. А давайте не будем сервера держать по выходным. Но отчёты по тестам в понедельник я хочу. А сервера по выходным не включайте. Это вместо того, чтобы настроить нормально автостарт и автостоп для окружений. Но менеджер же не хочет знать. Это же для него технические детали, хотя тут речь про деньги. А так да, мир такой - все что просто, стоит дополнительных расходов. Хочешь сэкономить - придётся освоить довольно сложные схемы и автоматизацию. Если и дорого и слишком сложно, то зачем вообще начинать проект? Можно же совсем ничего не делать.
Вы же сами написали, что DevOps - выделенная команда, а не проектная. У них таких проектов как ваш может быть довольно много. Т.е. они не могут работать в линейной иерархии, как обычный проект. Там просто нет выхода как работать по матрице. А в случае матричной структуры, без тикетов - никак. Вот есть у них, например, 50 проектов. И возможно ваш - далеко не самый приоритетный. Если дать возможность влиять напрямую, то вы его "пропихнете". Именно поэтому, вводится изоляция команды DevOps и тикеты. Только с помощью тикетов и их приоритезации, можно не поехать кукухой в этом хаосе. И да, вам неприятно, ваши личные метрики идут на дно. Но для компании в целом, возможно, это было меньшим злом и выгоднее, возможно были 5 других более важных и денежных проектов, которые взлетели за ваш счёт. Это всё конечно теория и домыслы как должно быть. Конкретный кейс может быть вовсе не таким счастливым.
Позволю себе немножко не согласиться. Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания, а чем-то более вразумительный и приближенным к делам, компании, продукту и процессу. Поток сознания может выливать только заказчик, который платит деньги. И только это может оправдывать такое поведение. Все остальные в рамках компании - это сотрудники осваивающие деньги клиентов и в идеале приносящие этим самым клиентам пользу. Но вот когда менеджер начинает вести себя как клиент, получая такую же зарплату и не оплачивая труд других из своего кармана. То это просто воровство ресурсов компании временем других сотрудников, которые не обязаны разбирать такие потоки. Для этого и есть менеджер, а если он не может то бизнес-аналитик. Который переводит с потоков на понятный технический язык. Технари должны получить задачу и выполнить ее, а не переводить поток сознания во что-то человеко-разборчивое. Это весьма непростое и стоящее многих нервов занятие.
Я вот работаю с помощью AI и хочу сказать, что год назад он давал более толковые и полезные советы.
Все очень сильно зависит от стека и насколько оно есть в свободном доступе на GitHub. Например, Java Spring или Selenium - без проблем. API все мейнстримные - тоже. Пробовал Robot Franework, всё намного хуже. Какой-нибудь Grafana K6 на JS - вообще прям печаль. А полезешь в эмбедед, так вообще засада полная, он про даташиты и прочие доки на чипы вообще почти ничего не знает. Если только чип старый и полно примеров кода, может что-то вытянуть.
Я вот работал на медицинском проекте. Там внезапно, перед тем как написать хоть строчку кода, нужно пройти пачку тренингов и подписаться, что ты их прошел. Иначе весь проект в топку и "Миша, давай по-новой." Как быть? ИИ подпишется? Ну и это для всего safety critical и military. Разработчик - это не просто кнопки давить, но ещё и "козёл отпущения", в случае чего.
А тут кажется, что у вас с архитектурой беда или с политиками чистого кода. Как девочка залила данные в таблицу, которую нужно было удалить? Что эта таблица вообще делала в мастере? У меня на всех проектах за такое по рукам били, если неиспользуемый код оставался, это просто ревью не могло пройти.
Люто-бешено плюсую. Дошли до стадии. Мне проще самому баги фиксить и комитить, чем девелоперам объяснять и писать трёх страничное описание с картинками, схемами и диаграммами, которые сами девелоперы не осилили.
Я как-то раз решил FreeBSD 9, если не ошибаюсь установить на Pentium MMX 166 MHz. Просто лежал без дела на балконе. Неделю ядро пересобиралось. Но потом зашевелилось даже.
Прекрасная статья, спасибо за неё. Есть рецепт решения ещё одной проблемы? Как поменять команду/компанию, когда она не хочет меняться? У меня сейчас полный день сурка, потому что всем нужно объяснять буквально как дышать. Документацию писать не хотят, потому что - "это невозможно". Правильно выставлять статусы тикетов - "нет, не хочу". Пользоваться версиями - "нет, мне сложно". Любые попытки, сделать что-то правильно, разбиваются о - мне лень это делать, если хочешь можешь сделать это сам за меня. А я буду делать только то что мне интересно.
Я не понимаю, почему в каждой компании хотят переопределить роли. Есть же ISTQB. Который, как минимум описывает роли Tester, Automated Tester, Test Manager. Писать тест план и стратегию - это задача никак не рядового тестировщика. Там слишком много завязок на менеджмент, разработчиков и расписание проекта. Знать которые, вообще не компетенция рядового тестировщика. А когда на проекте тестировщик в единственном экземпляре, я ещё ни разу не видел даже вменяемых требований. А без требований вся тест стратегия и план не имеют смысла. Потому что только отталкиваясь от требований, можно сделать осознанный выбор стека инструментов, языков программирования видов и типов тестирования, тестового окружения и фикстур. Ну и построить traceability matrix. Что до SDET, то SDET как правило не занимается тестами в отличие от Automated Test Engineer. SDET занимается реализацией задач от Test Architect. Прописыванием тест фреймворка его архитектурой, разбивкой на модули, включение зависимостей. Зачастую это выливается в дополнительный уровень абстракции под конкретный продукт. Поверх базовых RestAssured/Selenium/Requests/Appium/RobotFramework etc. Реализацией моков/стабов/симуляторов. DevOps команда прикручивает пайплайны к этому всему, а автоматизаторы прописывают уже сами тест-кейсы со сценариями с или без BDD/DDT. Тогда автоматизаторы просто получают API с CRUD операциями вся логика тестов прописывается на данном уровне абстракции. А там уже легко подменяя более низкоуровневую абстракцию. Одни и те же сценарии можно использовать например как для API тестирования, так и для UI. Это если как оно работает в идеале. Ну а если, где-то начинается экономия, то соответственно пойдут и компромиссы и кому-то придется совмещать роли. Ну и времени и сил прописывать дополнительные слои абстракции - не будет.
Тестировщик - это не совсем часть разработки. Это этап между разработкой и приемной, чтобы сэкономить нервы бизнесу принимающему результат. Если заказчику, внутреннему или внешнему, показать результат первого билда напрямую от разработчиков. То скорее всего у него будет нервный тик и лёгкая паника. А вот если показать 3, 5, 10 после тестировщиков. То шансы на продление контракта и новые заказы вырастут по параболе. А вот QA - это совсем не про разработку. QA ликвидирует баги не только кучей разных методов и методик тестирования. Но он просто уничтожает их пока они даже случились. Благодаря внедрению правильных процессов, улучшению коммуникации, документации, прототипирования ну и CI/CD. До сих пор существуют компании, которые вместо использования Figma, пытаются договориться о дизайне в Excel и на пальцах. Что только делает shift left огромного количества проблем и багов. Которые легко можно было бы обсудить и отстрелить просто сделав адекватные против за пару недель.
В Южной Европе вы узнаете, что мясо далеко не самый дорогой продукт. Например рыба, которую в Архангельске за еду не считают. Может стоить в разы дороже. Например, в Греции килограмм свежевыловленной рыбы стоит от 40 евро на рынке. В таверне от 80. Мясо 8-12 евро за кило в магазине. Причем от вида мяса разница в цене на уровне погрешности. Курица, свинина, говядина, баранина. Филе курицы стоит за частую столько же или больше чем свинина, может догонять говядину. Не пытайтесь понять рассчет цен, он тут свой особенный. Никакой себестоимости, все зависит от того сколько за сегодня уже заработали. На рынке под конец, рыбу которую продавали по 25 Евро за кило с фермы, могут отдавать за 10. Овощи, салаты, зелень вообще могут бесплатно отдать, лишь бы назад не складывать и не везти. Грибы - весьма дорогой продукт, дороже мяса, особенно лесные. Свежие ягоды тоже, потому что в этом климате не растут. Греческое блюдо Гирос грамм 200 жирной свинины на вертеле, картофель фри, лук и помидор стоит дешевле чем тарелка Греческого салата. Правда и салат тут это на 2-3 человека. Оливки - тоже не самое дешевле блюдо может быть дороже мяса, фисташки, и т.д. так что да фрукты овощи - стоят почти ничего. Но также довольно много растительной пищи дороже мяса и морепродукты.
Может в Гугле все и прекрасно. Но зачастую это все разбивается о нещадную суровость бытия. Проблемы коммуникации, косяки в документации из-за чего бесконечные митинги и прочая бюрократия. Были у меня проекты и более-менее ничего. Но что-то последнее время народ вообще не понимает, что нужно хотя бы перечитать, то что ты написал, чтобы другие потом не убивались неделю. Ну и что писать вообще полезно, чтобы 25 человек потом не приходили к тебе по очереди с вопросами. А ещё неплохо бы там требования всякие набросать, архитектуру. А не переделывать это все 5 раз на месяц и доказывать, что по-другому просто не может быть.
Самая длинная пробка была на Сербско-Венгерской границе. Но там все стояли пока проверят. Вообще я так понимаю, что электромобили в новости больше для хайпа. Тут нужно понимать, что в Греции зимняя резина - отсутствует как понятие, ну по-крайней мере в Аттиках, где находиться Арахово. Те пару дней в году со снегом - просто сидят дома пока не растает. Поэтому требуют иметь цепи или аналоги, которые одевают прямо на летнюю резину. Но многие на это забивают от чего и получается большая часть проблем и пробок в снегу. Может там и встряли электрокары, но скорее всего потому что небыло цепей и они летней резиной полировали снег пока аккумулятор не сел.
Тут всё очень зависит от продукта и круга пользователей. Для международных бизнесов и сервисов можно без облаков, но тогда нужно ставить своё оборужование распределенно в мире. Требования регуляторов и для улучщения доступа. Если компания международная, но еще не уровня FAANG и не готова строить собственные датацентры, то облачные решения вполне себе выход. А соответственно и нагрузку лучше подавать из облаков. Я сейчас занимался анализом и подбором инструмента подходящего для нагрузочного тестирования. jMeter - не впечатлил наборами тестов в XML формате. Хотя, возможно, я что-то не до конца понял. K6 выбрали, так как нам нужны специфические плагины, а продукт написан на GoLang. Так что разработчики смогут помочь с плагинами. Хотя если бы не это условие, я бы остановился на Gatling. Совместная инфраструктура кода тестов и самого фреймворка - гораздо лучше в перспективе. Ну и полный доступ к библиотекам Java/Scala тоже огромный плюс. В K6 - нужно писать тесты на JS, но при этом нет поддержки Node.js, т.е. лишаешся огромного колличества библиотек. Банально для работы с файлами уже нужны сторонние библиотеки. Также не впечатляет ограничение на запуск единственного файла с тестами. Пока еще только думаю как с этим жить. Т.е. нормально разложить тетсы по файлам, чтобы не иметь простыни на кучу строк - не очень-то получается. Вроде как можно импортить файлы, но тогда не понятно как быть с тагами и как выбирать что импортировать. Пока что самый очевидный способ управлять группами тестов - это банально указывать разные файлы на уровне пайплайна, что не самое удобное решение.
Как я понимаю здесь подготавливается сообщение для чат бота со ссылками на дашборд в Grafana. Но что там будет пока не установлены переменные для Prometheus приведенные в конце статьи?
В моём случае мы сразу создали отдельные проект для K6, потому что нам нужны свои плагины, которые там и будут лежать. Ну и если нужно часто пересобирать, можно также триггерить другой проект. Он выкладывает файл в registry, а проект с тестами забирает его оттуда. Ну и можно также скачать для локальных запусков не собирая локально.
Для себя как раз наткнулся, что на Prometheus не включена опция remote-write и не могу отправить туда данные, endpoint /api/v1/write отвечает 404. Может также кому-то поможет, кто будет настраивать с нуля.
Хорошая статья. Особенно отлично описаны mock, stub, fake. Сколько видел сломанных копий на эту тему.
Для определения require и assert есть установившаяся в тестировании терминология: soft assert - проверяет результат и разрешает продолжение теста, hard assert проверяет результат и останавливает тест в случае фейла.
Да должен. Он не должен это уметь делать. Но знать разницу между двумя словами и разницу в стоимости и применимости для его проекта знать обязан. Контейнеризация дешевле в использовании, как по эксплуатации, так и банально по стоимости у облаков. Но, не все проекты можно делать на ней.
А вот это вообще root cause 90% провалом на проектах. Когда хотят "скраежопить", абсолютно не понимая чем это обернется.
Не хотим держать свои сервера, CapEx - зло, переходим на облака, мы любим OpEx. И по налогам приятнее и денег сразу столько не нужно. А потом прибегает менеджер. Ой, что-то там такой счёт выставили из облаков. А давайте не будем сервера держать по выходным. Но отчёты по тестам в понедельник я хочу. А сервера по выходным не включайте. Это вместо того, чтобы настроить нормально автостарт и автостоп для окружений. Но менеджер же не хочет знать. Это же для него технические детали, хотя тут речь про деньги.
А так да, мир такой - все что просто, стоит дополнительных расходов. Хочешь сэкономить - придётся освоить довольно сложные схемы и автоматизацию.
Если и дорого и слишком сложно, то зачем вообще начинать проект? Можно же совсем ничего не делать.
Вы же сами написали, что DevOps - выделенная команда, а не проектная. У них таких проектов как ваш может быть довольно много. Т.е. они не могут работать в линейной иерархии, как обычный проект. Там просто нет выхода как работать по матрице. А в случае матричной структуры, без тикетов - никак.
Вот есть у них, например, 50 проектов. И возможно ваш - далеко не самый приоритетный. Если дать возможность влиять напрямую, то вы его "пропихнете". Именно поэтому, вводится изоляция команды DevOps и тикеты. Только с помощью тикетов и их приоритезации, можно не поехать кукухой в этом хаосе. И да, вам неприятно, ваши личные метрики идут на дно. Но для компании в целом, возможно, это было меньшим злом и выгоднее, возможно были 5 других более важных и денежных проектов, которые взлетели за ваш счёт.
Это всё конечно теория и домыслы как должно быть. Конкретный кейс может быть вовсе не таким счастливым.
Позволю себе немножко не согласиться. Поток сознания от PM - это повод найти нормального PM, который общается не потоком сознания, а чем-то более вразумительный и приближенным к делам, компании, продукту и процессу.
Поток сознания может выливать только заказчик, который платит деньги. И только это может оправдывать такое поведение. Все остальные в рамках компании - это сотрудники осваивающие деньги клиентов и в идеале приносящие этим самым клиентам пользу. Но вот когда менеджер начинает вести себя как клиент, получая такую же зарплату и не оплачивая труд других из своего кармана. То это просто воровство ресурсов компании временем других сотрудников, которые не обязаны разбирать такие потоки. Для этого и есть менеджер, а если он не может то бизнес-аналитик. Который переводит с потоков на понятный технический язык. Технари должны получить задачу и выполнить ее, а не переводить поток сознания во что-то человеко-разборчивое. Это весьма непростое и стоящее многих нервов занятие.
Учить AI - это конечно полезно. Но:
Галлюцинации, никто не отменял.
Я вот работаю с помощью AI и хочу сказать, что год назад он давал более толковые и полезные советы.
Все очень сильно зависит от стека и насколько оно есть в свободном доступе на GitHub. Например, Java Spring или Selenium - без проблем. API все мейнстримные - тоже. Пробовал Robot Franework, всё намного хуже. Какой-нибудь Grafana K6 на JS - вообще прям печаль. А полезешь в эмбедед, так вообще засада полная, он про даташиты и прочие доки на чипы вообще почти ничего не знает. Если только чип старый и полно примеров кода, может что-то вытянуть.
Я вот работал на медицинском проекте. Там внезапно, перед тем как написать хоть строчку кода, нужно пройти пачку тренингов и подписаться, что ты их прошел. Иначе весь проект в топку и "Миша, давай по-новой." Как быть? ИИ подпишется? Ну и это для всего safety critical и military. Разработчик - это не просто кнопки давить, но ещё и "козёл отпущения", в случае чего.
А тут кажется, что у вас с архитектурой беда или с политиками чистого кода. Как девочка залила данные в таблицу, которую нужно было удалить? Что эта таблица вообще делала в мастере? У меня на всех проектах за такое по рукам били, если неиспользуемый код оставался, это просто ревью не могло пройти.
За день сделаешь?
Сделаю.
А за 2?
Можно и за 2.
А за неделю?
Нет, за неделю не могу. Тут помощник нужен. (с)
Люто-бешено плюсую.
Дошли до стадии. Мне проще самому баги фиксить и комитить, чем девелоперам объяснять и писать трёх страничное описание с картинками, схемами и диаграммами, которые сами девелоперы не осилили.
А как же Gattling?
Я как-то раз решил FreeBSD 9, если не ошибаюсь установить на Pentium MMX 166 MHz. Просто лежал без дела на балконе. Неделю ядро пересобиралось. Но потом зашевелилось даже.
Прекрасная статья, спасибо за неё.
Есть рецепт решения ещё одной проблемы?
Как поменять команду/компанию, когда она не хочет меняться?
У меня сейчас полный день сурка, потому что всем нужно объяснять буквально как дышать.
Документацию писать не хотят, потому что - "это невозможно".
Правильно выставлять статусы тикетов - "нет, не хочу".
Пользоваться версиями - "нет, мне сложно".
Любые попытки, сделать что-то правильно, разбиваются о - мне лень это делать, если хочешь можешь сделать это сам за меня. А я буду делать только то что мне интересно.
Я не понимаю, почему в каждой компании хотят переопределить роли. Есть же ISTQB. Который, как минимум описывает роли Tester, Automated Tester, Test Manager.
Писать тест план и стратегию - это задача никак не рядового тестировщика. Там слишком много завязок на менеджмент, разработчиков и расписание проекта. Знать которые, вообще не компетенция рядового тестировщика. А когда на проекте тестировщик в единственном экземпляре, я ещё ни разу не видел даже вменяемых требований. А без требований вся тест стратегия и план не имеют смысла. Потому что только отталкиваясь от требований, можно сделать осознанный выбор стека инструментов, языков программирования видов и типов тестирования, тестового окружения и фикстур. Ну и построить traceability matrix.
Что до SDET, то SDET как правило не занимается тестами в отличие от Automated Test Engineer. SDET занимается реализацией задач от Test Architect. Прописыванием тест фреймворка его архитектурой, разбивкой на модули, включение зависимостей. Зачастую это выливается в дополнительный уровень абстракции под конкретный продукт. Поверх базовых RestAssured/Selenium/Requests/Appium/RobotFramework etc. Реализацией моков/стабов/симуляторов. DevOps команда прикручивает пайплайны к этому всему, а автоматизаторы прописывают уже сами тест-кейсы со сценариями с или без BDD/DDT.
Тогда автоматизаторы просто получают API с CRUD операциями вся логика тестов прописывается на данном уровне абстракции. А там уже легко подменяя более низкоуровневую абстракцию. Одни и те же сценарии можно использовать например как для API тестирования, так и для UI.
Это если как оно работает в идеале. Ну а если, где-то начинается экономия, то соответственно пойдут и компромиссы и кому-то придется совмещать роли. Ну и времени и сил прописывать дополнительные слои абстракции - не будет.
Тестировщик - это не совсем часть разработки. Это этап между разработкой и приемной, чтобы сэкономить нервы бизнесу принимающему результат. Если заказчику, внутреннему или внешнему, показать результат первого билда напрямую от разработчиков. То скорее всего у него будет нервный тик и лёгкая паника. А вот если показать 3, 5, 10 после тестировщиков. То шансы на продление контракта и новые заказы вырастут по параболе.
А вот QA - это совсем не про разработку. QA ликвидирует баги не только кучей разных методов и методик тестирования. Но он просто уничтожает их пока они даже случились. Благодаря внедрению правильных процессов, улучшению коммуникации, документации, прототипирования ну и CI/CD.
До сих пор существуют компании, которые вместо использования Figma, пытаются договориться о дизайне в Excel и на пальцах.
Что только делает shift left огромного количества проблем и багов. Которые легко можно было бы обсудить и отстрелить просто сделав адекватные против за пару недель.
В Южной Европе вы узнаете, что мясо далеко не самый дорогой продукт.
Например рыба, которую в Архангельске за еду не считают. Может стоить в разы дороже. Например, в Греции килограмм свежевыловленной рыбы стоит от 40 евро на рынке. В таверне от 80. Мясо 8-12 евро за кило в магазине. Причем от вида мяса разница в цене на уровне погрешности. Курица, свинина, говядина, баранина. Филе курицы стоит за частую столько же или больше чем свинина, может догонять говядину. Не пытайтесь понять рассчет цен, он тут свой особенный. Никакой себестоимости, все зависит от того сколько за сегодня уже заработали. На рынке под конец, рыбу которую продавали по 25 Евро за кило с фермы, могут отдавать за 10. Овощи, салаты, зелень вообще могут бесплатно отдать, лишь бы назад не складывать и не везти.
Грибы - весьма дорогой продукт, дороже мяса, особенно лесные. Свежие ягоды тоже, потому что в этом климате не растут.
Греческое блюдо Гирос грамм 200 жирной свинины на вертеле, картофель фри, лук и помидор стоит дешевле чем тарелка Греческого салата. Правда и салат тут это на 2-3 человека.
Оливки - тоже не самое дешевле блюдо может быть дороже мяса, фисташки, и т.д. так что да фрукты овощи - стоят почти ничего. Но также довольно много растительной пищи дороже мяса и морепродукты.
Может в Гугле все и прекрасно. Но зачастую это все разбивается о нещадную суровость бытия.
Проблемы коммуникации, косяки в документации из-за чего бесконечные митинги и прочая бюрократия. Были у меня проекты и более-менее ничего. Но что-то последнее время народ вообще не понимает, что нужно хотя бы перечитать, то что ты написал, чтобы другие потом не убивались неделю. Ну и что писать вообще полезно, чтобы 25 человек потом не приходили к тебе по очереди с вопросами. А ещё неплохо бы там требования всякие набросать, архитектуру. А не переделывать это все 5 раз на месяц и доказывать, что по-другому просто не может быть.
Самая длинная пробка была на Сербско-Венгерской границе. Но там все стояли пока проверят.
Вообще я так понимаю, что электромобили в новости больше для хайпа. Тут нужно понимать, что в Греции зимняя резина - отсутствует как понятие, ну по-крайней мере в Аттиках, где находиться Арахово. Те пару дней в году со снегом - просто сидят дома пока не растает. Поэтому требуют иметь цепи или аналоги, которые одевают прямо на летнюю резину. Но многие на это забивают от чего и получается большая часть проблем и пробок в снегу. Может там и встряли электрокары, но скорее всего потому что небыло цепей и они летней резиной полировали снег пока аккумулятор не сел.
Проехал неделю назад на электрокаре из Афин в Гданьск 2500 км. Что я делаю не так?
Тут всё очень зависит от продукта и круга пользователей. Для международных бизнесов и сервисов можно без облаков, но тогда нужно ставить своё оборужование распределенно в мире. Требования регуляторов и для улучщения доступа. Если компания международная, но еще не уровня FAANG и не готова строить собственные датацентры, то облачные решения вполне себе выход. А соответственно и нагрузку лучше подавать из облаков.
Я сейчас занимался анализом и подбором инструмента подходящего для нагрузочного тестирования.
jMeter - не впечатлил наборами тестов в XML формате. Хотя, возможно, я что-то не до конца понял. K6 выбрали, так как нам нужны специфические плагины, а продукт написан на GoLang. Так что разработчики смогут помочь с плагинами.
Хотя если бы не это условие, я бы остановился на Gatling. Совместная инфраструктура кода тестов и самого фреймворка - гораздо лучше в перспективе. Ну и полный доступ к библиотекам Java/Scala тоже огромный плюс.
В K6 - нужно писать тесты на JS, но при этом нет поддержки Node.js, т.е. лишаешся огромного колличества библиотек. Банально для работы с файлами уже нужны сторонние библиотеки.
Также не впечатляет ограничение на запуск единственного файла с тестами. Пока еще только думаю как с этим жить. Т.е. нормально разложить тетсы по файлам, чтобы не иметь простыни на кучу строк - не очень-то получается. Вроде как можно импортить файлы, но тогда не понятно как быть с тагами и как выбирать что импортировать.
Пока что самый очевидный способ управлять группами тестов - это банально указывать разные файлы на уровне пайплайна, что не самое удобное решение.
Я имею ввиду часть:
Как я понимаю здесь подготавливается сообщение для чат бота со ссылками на дашборд в Grafana. Но что там будет пока не установлены переменные для Prometheus приведенные в конце статьи?
В моём случае мы сразу создали отдельные проект для K6, потому что нам нужны свои плагины, которые там и будут лежать. Ну и если нужно часто пересобирать, можно также триггерить другой проект. Он выкладывает файл в registry, а проект с тестами забирает его оттуда. Ну и можно также скачать для локальных запусков не собирая локально.
Для себя как раз наткнулся, что на Prometheus не включена опция remote-write и не могу отправить туда данные, endpoint /api/v1/write отвечает 404. Может также кому-то поможет, кто будет настраивать с нуля.