Не нужно ни за кем ничего переписывать, это уже вопрос плохой организации, а не фреймворка. Просто не давайте лить плохой код и показывайте, как надо делать
Результат работы скрипта - это отчёт, из него уже составляется баг репорт. Не знаю, что вы ещё хотите от автотестов. Чтобы они разработчикам писали?
Если pytest ориентирован в первую очередь на unit тесты и писали его программисты для программистов - можно обозначить как это проявляется? Пишем API и UI тесты, юзаем фикстуры, все работает без проблем.
Поэтому там и отчёты отличные "из коробки" и KDD с BDD не требует дополнительных плагинов. Поэтому там и отчёты отличные "из коробки" и KDD с BDD не требует дополнительных плагинов. - Ну если для вас проблема сделать pip install allure-pytest, то да, достоинство. Я, конечно, не использовал те классные отчёты "из коробки", но аллюр как по мне прекрасно справляет со своей задачей и решает вопросы коммуникации ( не нужно писать репорт чтобы ввести человека в контекст)
Мне кажется, проблема не в выборе фреймворка, а в том, как люди делают тесты, как пишутся кейсы. Когда кейс состоит одного - двух шагов, когда нет аттачей с запросами / скриншотами/логами , когда нет докстринги в тестовой функции, когда нет возможности запуска теста кем-то кто не тестировщик или автоматизатор, вот тогда проблемы. А то, что новенькому надо посидеть недельку и разобраться, как питест работает - это вообще ничто по сравнению с плохим процессом или отсутствием процесса.
Асерты без строки, если свалится будет тупо питоновская ошибка, нужно копаться и вспоминать что там упало.
Тестовый класс и его метод без докстринги ( то что там урл написан ясности что в нём проверяется не даёт). Чтобы понять, что делает тест, надо читать код, лезть под капот, тратить время.
Инициализация клиента внутри тестового класса - не знаю, может и есть в этом что-то, но что если мы напишем другой клиент? Или у нас есть экземпляры клиента для разных случаев? И зачем вообще каждому тестовому классу свой клиент?
Файл с клиентом requests.py - зачем эта путаница? ну пусть бы был custom_client или ещё какой, но как основную либу для запросов то зачем называть?
Тестовая функция не принимает аргументов, значит нельзя её параметризировать, значит отпадает здоровый кусок функционала, который нам предоставляет PyTest. Если мы захотим сделать отрицательный тест, нам надо будет либо копипастить тестовую функцию, либо выносить параметры, чтобы их можно было перебирать через pytest.mark.parametrize
Когда дело дойдёт до запуска, эти тесты надо будет либо списком вызывать, либо по файлам распихивать, что одно что другое неудобно. Поэтому существую маркеры.
Так как у нас есть положительные и негативные тесты ...
Не увидел отрицательных тестов
Знаю, что мои замечания больше про большой проект, но всё же когда показываешь пример, надо или говорить что это автотест на один эндпоинт или уже показывать как масштабировать. Этот код не подходит для серьёзного проекта ( хотя бы потому что не используется питест)
Хоть автор и пишет, что он абстрагируется, толку от выноса импорта особо нет, поменять импорт при переходе на другую библиотеку - самое малое, что нужно будет сделать. Хочешь сделать на асинхронной либе - ну сделай сразу (хотя зачем, если есть xdist - непонятно).
Сразу извиняюсь если слишком токсично, у меня нет 17 лет опыта автоматизации, но если бы статья называлась "как улучшить плохой автотест" или вроде того, не было бы замечаний, а так не удержался.
По поводу переиспользования тестов с помощью фейкера - ну частично решает проблему, но гарантий уникальности не даёт. А для переиспользования тестов существуют фикстуры, которые сначала создают для теста нужные сущности а после себя чистят. После теста должен остаться только артефакт - отчёт или лог. А у вас база данных будет в куче пользователей.
Интересно глянуть, что он генерирует. Вообще с нормальным клиентом не вижу смысла использовать что-то генерёное. Накидать несколько ендпоинтов - не то, чтобы самое трудозатратное в автоматизации. Боди надо будет или самому вносить или проверять, хэдеры тоже. Как оно будет подтягивать изменения - непонятно, отдаём стабильность тестов на откуп команде бэкенда. Я бы не стал на серьёзном проекте таким заниматься, особенно если есть CI/CD
Так есть же такое решение, видел на ютубе, там парень делал клетки не помню какого размера и они были все соединены железкой. Но есть пара нюансов : он это делал в режиме песочницы и делал он это долго. Но теперь с этими чертежами можно свою базу построить. Опять же, пропускная способность ограничена железкой (выше чем у конвееров, но всё же ограничена)
Так в чем смысл этой Анны? Это тестовый фреймворк? Чем он лучше того же pytest ? Импортировать до кучи специальные асерты ещё. Отчёт в том же аллюре. Может ли Анна работать с ui тестами? Если нет, то это очень неудобно в том плане, что нужно тогда что-то ещё импортировать. Как по мне, аллюр + питест + реквесты - это удобно. Если надо ui тесты - мы просто добавляем selenium
Я пока читал, словил себя на мысли, что где-то есть несостыковка. Правда меня уже опередили. Да, люди с хорошим вкусом определяют ценность искусства, а людей с хорошим вкусом определяют по выбранному ими искусству. Самозацикливание получается.
Частицы могут хаотично взаимодействовать друг с другом, но наблюдатели, взаимодействующие с искусством, не относятся к таким частицам; их реакции не случайны — далеко не случайны.
Какая-то новая аксиома получается, ибо доказательств нет
Далее идёт абзац доказательства через аналогию, у вакцины есть общие свойства с искусством, но это не значит вообще ничего.
Отличная штука, но что делать, если общение выходит за рамки джиры?
Не совсем понял, как считаются связи в конфлюенсе — если я написал статью, а кто-то её прочитал — мы связаны? Я выкачал чью-то репу из битбакета — мы связаны?
У нас в команде основное общение происходит в телеге и дискорде, как это отразить в графе?
Классная статья!
Мы сейчас как раз пытаемся сделать интеграционные тесты, пока что только апи тесты и они на тестовом окружении со всей обвязкой, работают по 8 часов в несколько потоков.
Спасибо за статью, думаю, много чего сможем использовать ( в первую очередь инфраструктуру)
Например, в шахматах технически можно говорить о математической бесконечности количества возможных ходов, равного 1045, которые не трудно вычислить любому современному компьютеру.
Вращаться в плоскости винтов, как раз, отлично умеют. Смещаться за счёт крена, по сути, как вертолёт, только не за счёт сложного механизма перекоса, а за счёт изменения скорости вращения винтов. Но перемещаться вперёд, назад, вправо и влево они могут, хоть и за счёт крена.
Глупые киношники тратят огромные бабки на кадры, которые можно на коптер с али и гопро снять, тоже мне новость.
Покупают всякие алексы и крутят фокусное кольцо чуть ли не руками, про автофокус им не рассказали.
Доброго времени суток! Пытаюсь написать автотест, основанный на рохождении орграфа. В вашей статье написано про встраивание функции в ребро. Можете показать чуть более развернутый пример с обходом графа и выполнением функций на рёбрах? Доки курятся с трудом, а сроки горят. Заранее спасибо
Не нужно ни за кем ничего переписывать, это уже вопрос плохой организации, а не фреймворка. Просто не давайте лить плохой код и показывайте, как надо делать
Результат работы скрипта - это отчёт, из него уже составляется баг репорт. Не знаю, что вы ещё хотите от автотестов. Чтобы они разработчикам писали?
Если pytest ориентирован в первую очередь на unit тесты и писали его программисты для программистов - можно обозначить как это проявляется? Пишем API и UI тесты, юзаем фикстуры, все работает без проблем.
Поэтому там и отчёты отличные "из коробки" и KDD с BDD не требует дополнительных плагинов. Поэтому там и отчёты отличные "из коробки" и KDD с BDD не требует дополнительных плагинов. - Ну если для вас проблема сделать pip install allure-pytest, то да, достоинство. Я, конечно, не использовал те классные отчёты "из коробки", но аллюр как по мне прекрасно справляет со своей задачей и решает вопросы коммуникации ( не нужно писать репорт чтобы ввести человека в контекст)
Мне кажется, проблема не в выборе фреймворка, а в том, как люди делают тесты, как пишутся кейсы. Когда кейс состоит одного - двух шагов, когда нет аттачей с запросами / скриншотами/логами , когда нет докстринги в тестовой функции, когда нет возможности запуска теста кем-то кто не тестировщик или автоматизатор, вот тогда проблемы. А то, что новенькому надо посидеть недельку и разобраться, как питест работает - это вообще ничто по сравнению с плохим процессом или отсутствием процесса.
Асерты без строки, если свалится будет тупо питоновская ошибка, нужно копаться и вспоминать что там упало.
Тестовый класс и его метод без докстринги ( то что там урл написан ясности что в нём проверяется не даёт). Чтобы понять, что делает тест, надо читать код, лезть под капот, тратить время.
Инициализация клиента внутри тестового класса - не знаю, может и есть в этом что-то, но что если мы напишем другой клиент? Или у нас есть экземпляры клиента для разных случаев? И зачем вообще каждому тестовому классу свой клиент?
Файл с клиентом requests.py - зачем эта путаница? ну пусть бы был custom_client или ещё какой, но как основную либу для запросов то зачем называть?
Тестовая функция не принимает аргументов, значит нельзя её параметризировать, значит отпадает здоровый кусок функционала, который нам предоставляет PyTest. Если мы захотим сделать отрицательный тест, нам надо будет либо копипастить тестовую функцию, либо выносить параметры, чтобы их можно было перебирать через pytest.mark.parametrize
Когда дело дойдёт до запуска, эти тесты надо будет либо списком вызывать, либо по файлам распихивать, что одно что другое неудобно. Поэтому существую маркеры.
Не увидел отрицательных тестов
Знаю, что мои замечания больше про большой проект, но всё же когда показываешь пример, надо или говорить что это автотест на один эндпоинт или уже показывать как масштабировать. Этот код не подходит для серьёзного проекта ( хотя бы потому что не используется питест)
Хоть автор и пишет, что он абстрагируется, толку от выноса импорта особо нет, поменять импорт при переходе на другую библиотеку - самое малое, что нужно будет сделать. Хочешь сделать на асинхронной либе - ну сделай сразу (хотя зачем, если есть xdist - непонятно).
Сразу извиняюсь если слишком токсично, у меня нет 17 лет опыта автоматизации, но если бы статья называлась "как улучшить плохой автотест" или вроде того, не было бы замечаний, а так не удержался.
По поводу переиспользования тестов с помощью фейкера - ну частично решает проблему, но гарантий уникальности не даёт. А для переиспользования тестов существуют фикстуры, которые сначала создают для теста нужные сущности а после себя чистят. После теста должен остаться только артефакт - отчёт или лог. А у вас база данных будет в куче пользователей.
Интересно глянуть, что он генерирует. Вообще с нормальным клиентом не вижу смысла использовать что-то генерёное. Накидать несколько ендпоинтов - не то, чтобы самое трудозатратное в автоматизации. Боди надо будет или самому вносить или проверять, хэдеры тоже. Как оно будет подтягивать изменения - непонятно, отдаём стабильность тестов на откуп команде бэкенда. Я бы не стал на серьёзном проекте таким заниматься, особенно если есть CI/CD
Так есть же такое решение, видел на ютубе, там парень делал клетки не помню какого размера и они были все соединены железкой. Но есть пара нюансов : он это делал в режиме песочницы и делал он это долго. Но теперь с этими чертежами можно свою базу построить. Опять же, пропускная способность ограничена железкой (выше чем у конвееров, но всё же ограничена)
есть паттерн "main bus" для факторио
Здорово, что автоматизирует мобилки, но как пользователь я вообще не чувствую качества. Есть куда расти, успехов вам.
Так в чем смысл этой Анны? Это тестовый фреймворк? Чем он лучше того же pytest ? Импортировать до кучи специальные асерты ещё. Отчёт в том же аллюре. Может ли Анна работать с ui тестами? Если нет, то это очень неудобно в том плане, что нужно тогда что-то ещё импортировать. Как по мне, аллюр + питест + реквесты - это удобно. Если надо ui тесты - мы просто добавляем selenium
Я пока читал, словил себя на мысли, что где-то есть несостыковка. Правда меня уже опередили. Да, люди с хорошим вкусом определяют ценность искусства, а людей с хорошим вкусом определяют по выбранному ими искусству. Самозацикливание получается.
Какая-то новая аксиома получается, ибо доказательств нет
Далее идёт абзац доказательства через аналогию, у вакцины есть общие свойства с искусством, но это не значит вообще ничего.
Не совсем понял, как считаются связи в конфлюенсе — если я написал статью, а кто-то её прочитал — мы связаны? Я выкачал чью-то репу из битбакета — мы связаны?
У нас в команде основное общение происходит в телеге и дискорде, как это отразить в графе?
Мы сейчас как раз пытаемся сделать интеграционные тесты, пока что только апи тесты и они на тестовом окружении со всей обвязкой, работают по 8 часов в несколько потоков.
Спасибо за статью, думаю, много чего сможем использовать ( в первую очередь инфраструктуру)
Ничего не понял
Покупают всякие алексы и крутят фокусное кольцо чуть ли не руками, про автофокус им не рассказали.