вот есть для тех у кого много на jest-playwright

Приходи на NIX Edu Testing — определи свой уровень знаний вместе с NIX!

Сразу же в день мероприятия ты узнаешь, насколько сильны твои навыки, и сможешь попасть на бесплатное обучение в NIX!

Когда: 20–22 сентября, с 16:00 до 20:00
Где: Fabrika.space

Приглашаем тебя пройти тестирование по одной из 12-ти программ обучения: Java, PHP CMS, PHP Full Stack, Android, Business Analysis Education, Linux Administration/DevOps, .NET, Flutter, QA, Automation QA, Golang, JS/Front-End.

У нас нет скучных лекций и тонны конспектов! Ты будто попадаешь в настоящий IT-проект: здесь тебе и четкое распределение ролей в команде, и задачи, основанные на реальных кейсах, и возможность применять все свои знания. Ты получишь навыки для решения конкретных задач, и поймешь, как устроен IT-проект. После обучения мы ждем тебя в нашей команде на Junior позиции!

Регистрируйся по ссылке.

На тестирование обязательно возьми ноутбук, смартфон или планшет с возможностью подключения к Wi-Fi — задания ты будешь выполнять на своем девайсе.

Всем привет! Не подскажете, есть ли удобный способ, с помощью jest, сматчить 2 обьекта по ряду пропертей, а не по всем сразу? Но чтобы это была 1 проверка а не вереница expect`ов

о, спасибо!

Всем привет! Подскажите пожалуйста хорошую библиотеку для того чтобы прочекать текст в пдфке

Всем привет! Занимаюсь написанием тестов на апи, и меня преследуют муки выбора. Например, имеем эндпоинт, который возвращает данные о некотором объекте.
Для проверки этого эндпоинта нужно иметь объект в бд, данные которого будем запрашивать, и данные, которые ожидаем получить. Подскажите, как лучше заготавливать тестовые данные?
1. Создать объект в бд один раз, далее использовать его id в тесте. Объект, который ожидаем получить так же описан в тесте. Отправляем запрос, сравниваем полученный объект с имеющимся.
2. В тесте на получение объекта, сперва отправлять запрос на эндпоинт, который создает объект, а после уже на эндпоинт, который возвращает созданный объект. Сверить результат. Тут смущает то, что в тесте на получение данных используется эндпоинт, сохраняющий данные, и если он не работает, то тест на получение упадет.
3. Записать данные напрямую в базу из теста. Тут минус в том, что если запрашивать объект, данные которого собираются из 5 таблиц, то сперва все 5 нужно заполнить.

Привет. Я всегда выбираю 2ой вариант. +1 упавший тест это не +100, а накладных расходов сильно меньше, чем с остальными вариантами.

Очень у вас тут уютный канал, хочется сразу позадавать вопросы. Я занимаюсь разработкой Playwright и наши пользователи просят хороший аналог fetch / cy.request. Мы начали делать и как-то увлеклись, начали смотреть в сторону API testing.

Вопрос такой: насколько нам надо глубоко в эту область заходить? С одной стороны люди просят, с другой стороны есть axios, superagent, k6, swagger и вроде бы все и так довольны. Если есть у кого мнение на этот счет типа "и без вас хватает тулов" или "очень хочу такую фичу, но нигде не найду", поделитесь плиз?

Так же советую посмотреть в сторону json schema

вылетает при запуске дебага такая фигня в   wdio, обычный запуск нормально проходит, может кто-то сталкивался? устанавливал это iconv не помогает

я бы не сказал что прям много тулов есть. на деле сходу только chakram\supertest вспоминается. остальное все выглядит как - возьмем тестраннер, http клиент и библиотеку ассертов и соберем из этого велосипед решение.

Павел, привет. Мне кажется библиотека для отправки запросов и для тестирования апи – это немного разное. Но может это только в моей голове) То есть ещё один axios точно не нужен, а вот какие-нибудь интересные фичи – да :)

Собрать в кучу тулы и сделать удобный апи - может кому и пригодится. Но не знаю ваш ли это путь :) Вроде я видел не тянете ничего лишнего.

На основе UI-теста генерить спеку для апишки? Или хотя бы роуты, чтобы рутину не писать? Это было бы круто :))

Так вы должны понять, вы про браузер или про все что связано с тестами

Я бы сказал что удобного апи для работы с реквестами в прекондишинах было бы достаточно - все что уже есть в плейврайтн - перехват, подмена, модификация и тд. Полноценные тесты для работы с бекендом лучше писать в отдельном проекте имхо

Я думаю что такой метод имеет место быть, но не в качестве тестирования api, а для нужд ui и e2e тестов

Думаю, что пв должен хорошо делать одно - управлять браузером. Для остального есть экосистема nodejs

Что мешает сделать отдельный package с поддержкой любого раннера, в том числе pw- шного?)