Скажите, а зачем вы даете тестовое задание, чтобы что? Вам недостаточно просто поговорить? Ваши 8 пунктов говорят только о том, что у этих людей другой стиль написания тестов, чем принято в вашей компании (и вы даже про это сами говорите).
В моем понимании, единственное тестовое задание, которое может быть, это опросник/задачка, чтобы HR отсеивал совсем никаких
Как я писал выше, попробуйте мыслить не 1 тест, а "у нас тут много тестов и это все надо поддерживать"
Я выше писал, поддерживал ~5к апи тестов с различными версиями. Сначала тоже делал абстракции на абстракцию, потом все сильно упрощал, т.к. чем больше кода, тем сложнее стало в нем разбираться и метод "в лоб", сильно упростил написание и сопровождение тестов.
А как вы предлагаете решить проблему? Писать в лоб? Где та тонкая грань, когда тестов "много" (больше 5?) и стоит писать нужный код и раскидывать по всему проекту
Вы сами писали в комментариях, что разделяете тесты по логическим папкам. Зачем для этого тащить регистрацию куда-то дальше модуля проверяющего регистрацию (или всю логическую сущность в виду системы аутентификации)? Определение много/мало это лежит на коллективе, разрабатывающего эти тесты.
Так как в будущем вы будете использовать эти тесты в CI и вам надо будет прокидывать url через командную строку и/или переменную. Поэтому хардкодить не вариант
Предлагалось, как вы ниже и написали, использовать задавание урла в 1 месте. В вашем же примере данной статьи, вы показываете о задании в каждом тесте/инициализации клиента.
инверсия зависимости
Чтобы что? Боитесь, что requests надо будет заменять?
Эта модель не повторяет requests, эта наше собственная модель. В тестах мы независим от нижней реализации - requests. Где делать валидацию это вопрос для дальнейшего обсуждения, к сожалению, мне не хватит бумаги что бы за один заход рассказать как писать api тесты
Видимо не хватило этой статьи, чтобы объяснить для чего это, пока что, как и предыдущий вопрос, видится, что это для будущей замены requests.
Используем, сваггер это "книга данных", к в которую автотестор постоянно заглядывает и смотрит. В идеальной компании такой подход, когда мы доверимся полностью сваггеру и будем на основе его писать модели, сработал бы. Но я никогда не встречал "идеальный" сваггер, который 100% отражает действительность. Сваггер для меня это внешняя зависимость, а такие зависимости стараются убирать.
Но вы ведь его повторяете в своих тестах (в репозитории) описывая свои модели и у вас появляется теперь 2 вещи, где описана структура ответов от API и в случае проблемы, какой из реализаций доверять больше?
Я посмотрел ваш репозиторий, который вы указали, и там часть вопросов отпадает, реализовано (на мой взгляд) лучше.
к сожалению генерировать api клиент из сваггера для тестов не очень получается, т.к. зачастую в тестах необходимо что-то специфическое (добавить/удалить поле и т.п.), поэтому проще писать своего клиент, но вот использовать сваггер для валидации ответа прям отлично
А что не так с xdist? Я делал запуск xdist на сьюте из 5к API тестов, из которых 2-3к генерировались динамически при старте сьюта (тесты на различные версии апи). Надо учесть пару мелочей загрузки тестов и все.
Было очень обнадеживающее вступление, но прочитал и расстроился. Первоначальный тест читаемее в 10 раз итогового варианта.
У вас получился какой-то java подход с какими-то не нужными абстракциями (фабриками)
Зачем выделять в отдельную сущность регистрацию, если в 99% случаев мы напишем на этот кусочек кода 5 тестов и никогда больше к нему не вернемся? (в API тестах, как по мне, page object подход не работает абсолютно, он только создает кучу ненужного кода, раскиданого по всему проекту)
Зачем делать custom_request, но при этом все равно явно передавать ему url? У вас URL сервера не меняется на протяжении тестов, передайте его при инициализации.
Зачем каждой сущности типа Register, создавать своего клиента? http клиент должен быть 1 на весь прогон тестов (также, как и коннекты к базе и т.п.)
Зачем вообще нужен custom_request и свой клиент, если они под собой используют все равно requests? Если хочется свои обработки, то лучше у requests кастомную сессию определить
Зачем делать свою ResponseModel, если она не модель и повторяет ответы от requests? Если назвали моделью, то хоть минимальную валидацию данных в ней реализуйте
Вы упомянули swagger, но никак его не используете, зачем упомянули? По хорошему, на основе схемы надо реализовывать валидацию структуры и типов данных
так может у вас ретро не правильно проходит и его проще убрать? :)
у меня была подобная проблема, мы просто убрали ретро, т.к. смысла от него не было. Когда команда подросла, стали появляться вопросы, вернули ретро и оно стало проходить вполне продуктивно
я просто за уменьшение количества звонков вообще, слишком измучен этим "свободным форматом", когда на любой чих по звонку и час все сидят и обсуждают непонятно что
Если ретро не про результат работы, а про провести час времени в разговорах, то наверно развлекательный элемент это хорошо. Я предпочитаю ретро, когда понятно о чем будет идти речь и по существу (т.е. подготовлены вопросы, замечания, предложения), а не так, что все пришли, весело пообщались на не рабочие темы и разошлись
Т.е. вместо того, чтобы спокойно подключиться в зум, спокойно обговорить ретро за 30 минут и разойтись работать, вы заставили людей потратить время на установку и проверку игры, научиться в ней как-то жить, чтобы что? Ладно б у вас все люди играли в майнкрафт... Я бы на такое ретро не пошел, мое время мне дороже (все таки пришли работать, а не в игры играть)
Скажите, а зачем выставлять такую плашку? Пару раз видел таких людей, абсолютно непонятно для чего это. Если это личный аккаунт, то все понимают, что люди иногда спят или заняты чем-то, а не смотрят в ТГ 24/7. Если это корпоративный или рабочий, то там время работы +- должно стоять
Скажите, а где спрашивают такие вопросы про скрам? На роль скрам мастера?
но эта реставрация похожа на установку виниров и вообще на виниры? или совсем другое что-то?
Скажите, а зачем вы даете тестовое задание, чтобы что? Вам недостаточно просто поговорить? Ваши 8 пунктов говорят только о том, что у этих людей другой стиль написания тестов, чем принято в вашей компании (и вы даже про это сами говорите).
В моем понимании, единственное тестовое задание, которое может быть, это опросник/задачка, чтобы HR отсеивал совсем никаких
Не совсем из статьи, а как крепятся такие "реставрации"? По описанию технологии, очень похоже на виниры
Зачем тут postman, если используется k6?
Статья хорошая, но она не относится к QA только, у вас вполне общий подход получился
еще б их можно было где-то куптиь, хотя бы по 10 баксов
Я выше писал, поддерживал ~5к апи тестов с различными версиями. Сначала тоже делал абстракции на абстракцию, потом все сильно упрощал, т.к. чем больше кода, тем сложнее стало в нем разбираться и метод "в лоб", сильно упростил написание и сопровождение тестов.
Вы сами писали в комментариях, что разделяете тесты по логическим папкам. Зачем для этого тащить регистрацию куда-то дальше модуля проверяющего регистрацию (или всю логическую сущность в виду системы аутентификации)? Определение много/мало это лежит на коллективе, разрабатывающего эти тесты.
Предлагалось, как вы ниже и написали, использовать задавание урла в 1 месте. В вашем же примере данной статьи, вы показываете о задании в каждом тесте/инициализации клиента.
Чтобы что? Боитесь, что requests надо будет заменять?
Видимо не хватило этой статьи, чтобы объяснить для чего это, пока что, как и предыдущий вопрос, видится, что это для будущей замены requests.
Но вы ведь его повторяете в своих тестах (в репозитории) описывая свои модели и у вас появляется теперь 2 вещи, где описана структура ответов от API и в случае проблемы, какой из реализаций доверять больше?
Я посмотрел ваш репозиторий, который вы указали, и там часть вопросов отпадает, реализовано (на мой взгляд) лучше.
к сожалению генерировать api клиент из сваггера для тестов не очень получается, т.к. зачастую в тестах необходимо что-то специфическое (добавить/удалить поле и т.п.), поэтому проще писать своего клиент, но вот использовать сваггер для валидации ответа прям отлично
А что не так с xdist? Я делал запуск xdist на сьюте из 5к API тестов, из которых 2-3к генерировались динамически при старте сьюта (тесты на различные версии апи). Надо учесть пару мелочей загрузки тестов и все.
Было очень обнадеживающее вступление, но прочитал и расстроился. Первоначальный тест читаемее в 10 раз итогового варианта.
У вас получился какой-то java подход с какими-то не нужными абстракциями (фабриками)
Зачем выделять в отдельную сущность регистрацию, если в 99% случаев мы напишем на этот кусочек кода 5 тестов и никогда больше к нему не вернемся? (в API тестах, как по мне, page object подход не работает абсолютно, он только создает кучу ненужного кода, раскиданого по всему проекту)
Зачем делать custom_request, но при этом все равно явно передавать ему url? У вас URL сервера не меняется на протяжении тестов, передайте его при инициализации.
Зачем каждой сущности типа Register, создавать своего клиента? http клиент должен быть 1 на весь прогон тестов (также, как и коннекты к базе и т.п.)
Зачем вообще нужен custom_request и свой клиент, если они под собой используют все равно requests? Если хочется свои обработки, то лучше у requests кастомную сессию определить
Зачем делать свою ResponseModel, если она не модель и повторяет ответы от requests? Если назвали моделью, то хоть минимальную валидацию данных в ней реализуйте
Вы упомянули swagger, но никак его не используете, зачем упомянули? По хорошему, на основе схемы надо реализовывать валидацию структуры и типов данных
так может у вас ретро не правильно проходит и его проще убрать? :)
у меня была подобная проблема, мы просто убрали ретро, т.к. смысла от него не было. Когда команда подросла, стали появляться вопросы, вернули ретро и оно стало проходить вполне продуктивно
я просто за уменьшение количества звонков вообще, слишком измучен этим "свободным форматом", когда на любой чих по звонку и час все сидят и обсуждают непонятно что
а я вот наоборот, фотополимерник получается гладенький и не видно этих слоев и ступенек, так сильно
Если ретро не про результат работы, а про провести час времени в разговорах, то наверно развлекательный элемент это хорошо. Я предпочитаю ретро, когда понятно о чем будет идти речь и по существу (т.е. подготовлены вопросы, замечания, предложения), а не так, что все пришли, весело пообщались на не рабочие темы и разошлись
А что дает встреча в игре? Кроме как отвлечения людей от разговора, на "походить и потыкать новую штуку"?
Т.е. вместо того, чтобы спокойно подключиться в зум, спокойно обговорить ретро за 30 минут и разойтись работать, вы заставили людей потратить время на установку и проверку игры, научиться в ней как-то жить, чтобы что? Ладно б у вас все люди играли в майнкрафт... Я бы на такое ретро не пошел, мое время мне дороже (все таки пришли работать, а не в игры играть)
Вы изобрели QA аналитика?
Скажите, а зачем выставлять такую плашку? Пару раз видел таких людей, абсолютно непонятно для чего это. Если это личный аккаунт, то все понимают, что люди иногда спят или заняты чем-то, а не смотрят в ТГ 24/7. Если это корпоративный или рабочий, то там время работы +- должно стоять
100500 статья про декораторы на хабре