Комментарии 10
у pytest есть сотни плагинов, из которых можно получить любые фишки других фреймворков( можно добавить и bdd, и KDT и ещё несколько подходов которые тут не озвучены). Это позволяет иметь один фреймворк в компании\проекте с любыми расширениями. Так же данный фреймворк знают многие тестировщики и новый сотрудник быстрее включится в работу. В 2021 году использовать не pytest это стрелять себе в ногу.
Очень уж категорично. Да, pytest хорош, и я тоже не видел ему альтернативы, но потом потребовалось быстро написать тесты для клиента SAP и готовая библиотека нашлась для Robot Framework. Попробовал его в работе и он мне показался очень хорош для командной работы. Если результатом вашей работы должны быть не только баг репорты, то RF это неплохой выбор. Если pytest ориентирован в первую очередь на unit тесты и писали его программисты для программистов, то RF писался держа в голове проблему "трёх амиго" - проблему коммуникации внутри проекта. Поэтому там и отчёты отличные "из коробки" и KDD с BDD не требует дополнительных плагинов. Его тесты вполне могут служить документацией по продукту, понятной в том числе и заказчику. А вот это может оказаться очень важным.
Ну, и если мне потребуется быстро втаскивать мануальщиков в автоматизацию, я бы тоже предпочел RF. Написать для них "кубики" кийвордов или библиотеки будет быстрее и продуктивнее, чем переписывать тесты за ними.
Не нужно ни за кем ничего переписывать, это уже вопрос плохой организации, а не фреймворка. Просто не давайте лить плохой код и показывайте, как надо делать
Результат работы скрипта - это отчёт, из него уже составляется баг репорт. Не знаю, что вы ещё хотите от автотестов. Чтобы они разработчикам писали?
Если pytest ориентирован в первую очередь на unit тесты и писали его программисты для программистов - можно обозначить как это проявляется? Пишем API и UI тесты, юзаем фикстуры, все работает без проблем.
Поэтому там и отчёты отличные "из коробки" и KDD с BDD не требует дополнительных плагинов. Поэтому там и отчёты отличные "из коробки" и KDD с BDD не требует дополнительных плагинов. - Ну если для вас проблема сделать pip install allure-pytest, то да, достоинство. Я, конечно, не использовал те классные отчёты "из коробки", но аллюр как по мне прекрасно справляет со своей задачей и решает вопросы коммуникации ( не нужно писать репорт чтобы ввести человека в контекст)
Мне кажется, проблема не в выборе фреймворка, а в том, как люди делают тесты, как пишутся кейсы. Когда кейс состоит одного - двух шагов, когда нет аттачей с запросами / скриншотами/логами , когда нет докстринги в тестовой функции, когда нет возможности запуска теста кем-то кто не тестировщик или автоматизатор, вот тогда проблемы. А то, что новенькому надо посидеть недельку и разобраться, как питест работает - это вообще ничто по сравнению с плохим процессом или отсутствием процесса.
Не тянет это на топ "лучших фреймворков", ну вот совсем ни разу. Ни примера самих тестов не привели, ни адекватного сравнения - только примитивные копирайтные описания.
Из приведенного списка известна на самом деле только пара фреймворков, остальные сделаны на коленке парой энтузиастов, без документации и последний раз релизились в 2016 году. Зачем их использовать? Чтобы потом все переписывать на нормальный pytest? Так проще с самого начала на нем писать. Кому потом будут нужны специалисты, которые использовали эти фреймворки?
Была бы возможность, поставил бы статье минус.
Так это же перевод статьи Эндрю Найта какого-то лохматого года. Откуда там будет что-то свежее?
А нет, не Найта. Но, про то, что кроме pytest ничего не нужно, я бы поспорил. Другие фреймворки от него заметно отстают, но спрос на Robot Framework вполне заметный. За этот год в Москве было 44 вакансии с ним: https://clingon.pythonanywhere.com/unit_test_frameworks В "Касперском", например, его используют.
Robot Framework хорош только для примеров hello world, всё что сложнее: писать, дебажить, становится всё не удобнее и не удобнее с каждым методом написанным на нём, когда тестов больше несколько тысяч, на роботе можно вещаться. Никому не пожелаю такую работу. Пару раз приходилось в таком участвовать. На pytest в разы легче написать тесты чем dsl языке RF. А про поддержку, дебаг, и говорить нечего.
Чего-то сложного на нем действительно не писал, но там же все сложное пишется на обычном Python внутри кийвордов или библиотек. Про сложности с дебагом не понял. Для него же есть свои дебагеры, или они так плохи? С поддержкой у него все как у других FOSS продуктов — вся надежда на сообщество и документацию. Документация у него отличная. На мой взгляд, лучше чем у pytest: проще, понятнее и лучше структурирована. Есть не только справочники, но и руководства по архитектуре тестов: https://github.com/robotframework/HowToWriteGoodTestCases. Сообщество русскоязычное есть: https://t.me/robotframework_ru помощь там действительно можно найти, люди доброжелательные.
Я согласен, что если цель быстро писать тесты, то pytest - OK. Но, если нужен общий язык с аналитиком, мануальным тестировщиком, менеджером, заказчиком - то тут лучше что-то, что к человеческому языку ближе.
Хорошо это или плохо, но он заставляет вас работать в соответствии с заранее определенной методологией, поэтому поначалу кривая обучения может быть длиннее, чем обычно.
Еще и не правильной к тому же.
Парни не понимают вобще что такое жизненный цикл теста, и как он должен исполняться.
https://github.com/robotframework/robotframework/issues/3089
8! RSpec смотрит на это все ... с подозрением :D
8 лучших фреймворков для тестирования с помощью Python в 2021 году