В python из коробки неудобно пользоваться словарём, особенно при большой вложенности. Используете ли вы библиотеки, например attrs, marshmallows и подобные ? Как вы валидируете ответ в response, например обязательные поля, тип и длину ?
Добрый день! А такой вопрос - не стал ли ваш фреймфорк узким местом для ваших клиентов? И не придётся ли им каждый раз, при изменении системы, возвращаться к вам?
Был такой вариант, при котором они могли бы отдать тестирование своим разработчикам, думаю, плюс/минус они смогли бы написать e2e сценарии и своб систему они знают лучше (кто где после себя оставляет в базе)?
тестового пользователя, для условных get запросов, через тестовый фреймворк и дёргать его там , а не через бд? Или хранить пользователя в своей бд и оттуда его брать? Хранить id пользователя в файле при запуске тестов, если тесты особенно параллельны. И так далее.
Просто не было понятно, почему вы пришли к такому решению с redis, ещё и не совсем надёжном, так как с ваших слов кто-то может из тестеров "поломать" пользователя. Почему не рассматривалм "стандартные" решения для вашей проблемы и если рассматривали, то к чему пришли/какие проблемы были?
Раньше на каждый чих вы создавали нового пользователя и это было долго. Поэтому вы переиспользуете старых пользователей, которые "чистые" и их можно брать для тестов ?
Я выше писал, поддерживал ~5к апи тестов с различными версиями. Сначала тоже делал абстракции на абстракцию, потом все сильно упрощал, т.к. чем больше кода, тем сложнее стало в нем разбираться и метод "в лоб", сильно упростил написание и сопровождение тестов.
Мне трудно представить, что бы тот же фронт, например, писали в лоб, без использования MVC (не берем в расчет библиотеки) - на выходе будет неподдерживаемая каша. Но у вас в фирме приняли такое решение, это работает, ок)
Предлагалось, как вы ниже и написали, использовать задавание урла в 1 месте. В вашем же примере данной статьи, вы показываете о задании в каждом тесте/инициализации клиента.
Статья не про "куда нам деть url" ) Код в статье можно и нужно улучшать, но я бы начал с архитектуры, а потом думал об url
Чтобы что? Боитесь, что requests надо будет заменять?
Я не хочу показаться грубым или надменным и заранее извиняюсь, но когда я писал эту статью, мне с одной стороны казалось, что я буду писать про очевидные вещи, даже несмотря на то, сколько кода я видел в проде автотестеров. Но нет, я получил хороший, полезный и интересный отклик)
Но вы ведь его повторяете в своих тестах (в репозитории) описывая свои модели и у вас появляется теперь 2 вещи, где описана структура ответов от API и в случае проблемы, какой из реализаций доверять больше?
Например, в сваггере могут не описать 400 ошибки (и их модели) или копипастнуть. Если бы мой код лежал в одной репе с бэком(на питоне), то я просто бы забрал модели и переиспользовал бы их.
Первоначальный тест читаемее в 10 раз итогового варианта.
У вас получился какой-то java подход с какими-то не нужными абстракциями (фабриками)
Как я писал выше, попробуйте мыслить не 1 тест, а "у нас тут много тестов и это все надо поддерживать"
Зачем выделять в отдельную сущность регистрацию, если в 99% случаев мы напишем на этот кусочек кода 5 тестов и никогда больше к нему не вернемся? (в API тестах, как по мне, page object подход не работает абсолютно, он только создает кучу ненужного кода, раскиданого по всему проекту)
А как вы предлагаете решить проблему? Писать в лоб? Где та тонкая грань, когда тестов "много" (больше 5?) и стоит писать нужный код и раскидывать по всему проекту
Зачем делать custom_request, но при этом все равно явно передавать ему url? У вас URL сервера не меняется на протяжении тестов, передайте его при инициализации.
Так как в будущем вы будете использовать эти тесты в CI и вам надо будет прокидывать url через командную строку и/или переменную. Поэтому хардкодить не вариант
Зачем каждой сущности типа Register, создавать своего клиента? http клиент должен быть 1 на весь прогон тестов (также, как и коннекты к базе и т.п.)
"Так же хотелось бы отметить, что код ниже про архитектуру, некоторые вещи я намерено упрощаю, что бы не затягивать."
Здесь реализация через фикстуру и "должен быть 1 на весь прогон тестов", как пример
Зачем вообще нужен custom_request и свой клиент, если они под собой используют все равно requests? Если хочется свои обработки, то лучше у requests кастомную сессию определить
инверсия зависимости
Зачем делать свою ResponseModel, если она не модель и повторяет ответы от requests? Если назвали моделью, то хоть минимальную валидацию данных в ней реализуйте
Эта модель не повторяет requests, эта наше собственная модель. В тестах мы независим от нижней реализации - requests. Где делать валидацию это вопрос для дальнейшего обсуждения, к сожалению, мне не хватит бумаги что бы за один заход рассказать как писать api тесты
Вы упомянули swagger, но никак его не используете, зачем упомянули? По хорошему, на основе схемы надо реализовывать валидацию структуры и типов данных
Используем, сваггер это "книга данных", к в которую автотестор постоянно заглядывает и смотрит. В идеальной компании такой подход, когда мы доверимся полностью сваггеру и будем на основе его писать модели, сработал бы. Но я никогда не встречал "идеальный" сваггер, который 100% отражает действительность. Сваггер для меня это внешняя зависимость, а такие зависимости стараются убирать.
Как и написал выше, есть зависимость от проекта. На своем проекте мне пришлось выключить его, придётся переписывать фикстуры, изменился бэк. В соседней репе все работает прекрасно.
Если внутри команды есть договоренность, что этот уровень может использоваться в тестах (например, что бы чистить базу полбе себя или делать дополнительные проверки), то норм)
Добрый день !
1) почему именно Java? Сравнивали с другими языками? Какие плюсы?
2) какие сложности были в процессе обучения ? Хватило ли времени на обучение?
3) какого уровня специалисты вышли (джун, мидл)? Как они развивались дальше? Появился ли у них опытный тимлид?
4) что стало с их зп?
Добрый вечер. Спасибо статью!
В python из коробки неудобно пользоваться словарём, особенно при большой вложенности. Используете ли вы библиотеки, например attrs, marshmallows и подобные ? Как вы валидируете ответ в response, например обязательные поля, тип и длину ?
Добрый день! А такой вопрос - не стал ли ваш фреймфорк узким местом для ваших клиентов? И не придётся ли им каждый раз, при изменении системы, возвращаться к вам?
Был такой вариант, при котором они могли бы отдать тестирование своим разработчикам, думаю, плюс/минус они смогли бы написать e2e сценарии и своб систему они знают лучше (кто где после себя оставляет в базе)?
А рассматривали варианты, сделать
тестового пользователя, для условных get запросов, через тестовый фреймворк и дёргать его там , а не через бд? Или хранить пользователя в своей бд и оттуда его брать? Хранить id пользователя в файле при запуске тестов, если тесты особенно параллельны. И так далее.
Просто не было понятно, почему вы пришли к такому решению с redis, ещё и не совсем надёжном, так как с ваших слов кто-то может из тестеров "поломать" пользователя. Почему не рассматривалм "стандартные" решения для вашей проблемы и если рассматривали, то к чему пришли/какие проблемы были?
Я тогда не совсем понял, какую задачу вы решали (
Раньше на каждый чих вы создавали нового пользователя и это было долго. Поэтому вы переиспользуете старых пользователей, которые "чистые" и их можно брать для тестов ?
Добрый день! Я правильно понимаю, что для тестов вы используете только Postman, без авто ?
Статья перевод из 2018 ?)
спасибо. очень жду, жаль, что поздно уивидел объявление
Добрый день. Аможно где-то в записи посмотреть ?
Забить можно на всё, было бы желание)
Но с графаной вы в разы гибче настраиваете дашбоард, который приносит (для меня) пользу, а не дашборд ради дашборда
Спасибо. А почему не рассматривали вариант решить эту задачу через, например, Allure TestOps и строить дашборды и статистику там ?
А где вы храните тест кейсы ?
Золотые слова. А то из каждого утюга, что тестирование это просто, жми на кнопку и получай 300к
Может попросить тестировать/писать тесты разработчиков ?)
«Модульных тестов всегда больше, чем тестов с других уровней.»
Почему ?
Для чего тестировщику (особенно начинающему) знать Android Studio, XCode ?
Мне трудно представить, что бы тот же фронт, например, писали в лоб, без использования MVC (не берем в расчет библиотеки) - на выходе будет неподдерживаемая каша. Но у вас в фирме приняли такое решение, это работает, ок)
Статья не про "куда нам деть url" ) Код в статье можно и нужно улучшать, но я бы начал с архитектуры, а потом думал об url
Я не хочу показаться грубым или надменным и заранее извиняюсь, но когда я писал эту статью, мне с одной стороны казалось, что я буду писать про очевидные вещи, даже несмотря на то, сколько кода я видел в проде автотестеров. Но нет, я получил хороший, полезный и интересный отклик)
Например, в сваггере могут не описать 400 ошибки (и их модели) или копипастнуть. Если бы мой код лежал в одной репе с бэком(на питоне), то я просто бы забрал модели и переиспользовал бы их.
Как я писал выше, попробуйте мыслить не 1 тест, а "у нас тут много тестов и это все надо поддерживать"
А как вы предлагаете решить проблему? Писать в лоб? Где та тонкая грань, когда тестов "много" (больше 5?) и стоит писать нужный код и раскидывать по всему проекту
Так как в будущем вы будете использовать эти тесты в CI и вам надо будет прокидывать url через командную строку и/или переменную. Поэтому хардкодить не вариант
"Так же хотелось бы отметить, что код ниже про архитектуру, некоторые вещи я намерено упрощаю, что бы не затягивать."
Здесь реализация через фикстуру и "должен быть 1 на весь прогон тестов", как пример
инверсия зависимости
Эта модель не повторяет requests, эта наше собственная модель. В тестах мы независим от нижней реализации - requests. Где делать валидацию это вопрос для дальнейшего обсуждения, к сожалению, мне не хватит бумаги что бы за один заход рассказать как писать api тесты
Используем, сваггер это "книга данных", к в которую автотестор постоянно заглядывает и смотрит. В идеальной компании такой подход, когда мы доверимся полностью сваггеру и будем на основе его писать модели, сработал бы. Но я никогда не встречал "идеальный" сваггер, который 100% отражает действительность. Сваггер для меня это внешняя зависимость, а такие зависимости стараются убирать.
Как и написал выше, есть зависимость от проекта. На своем проекте мне пришлось выключить его, придётся переписывать фикстуры, изменился бэк. В соседней репе все работает прекрасно.
Если внутри команды есть договоренность, что этот уровень может использоваться в тестах (например, что бы чистить базу полбе себя или делать дополнительные проверки), то норм)