Есть срочная задача внедрить автотеститование с помощью Selenium на большом проекте, последние годы было только мануальное и программисты перед деплоем изменений про продакшн запускали unttestы на codeception.
Я взялся активно изучать webdriver и python, но пока что в программировании на python опыта очень мало.
Вопрос: подойдут ли такие этапы для грамотного внедрения автоматического тестирования?
Не является ли шаг 2. Создания юниттестов лишним?
1.Перед созданием юниттестов с помощью простого инструмента Selenium IDE надо создать тесткейсы, из них создать тест сьюты и регулярно запускать их на продакшене и на dev окружении.
Создание юниттестов
Используя Закон Парето “Правило 80/20" определить, какие 20% функционала используются чаще всего и покрыть его юниттестами.
3.Использование behaviour driven development фреймворка Behave https://pythonhosted.org/behave/
Чтобы написанные тесты было понятны даже не для человека из IT:
Feature: I want to search for topics
Scenario Outline: Search
Given I am on blog page
when I search for “football"
then I should see list of matching topics in search results
4.Настроить Jenkins CI или что-то подобное для постоянной прогонки тестовых сценариев и формирование отчетности:
лучше все-таки сразу на питоне биться, чем пользоваться Selenium IDE
а что Вы понимаете под юнит тестами? Unit Test и Selenium это ведь разные виды тестирования.
К тому же вы же сами писали :
почему выбор пал именно behaviour driven development?
Только, чтобы менеджер открывая тест, понимал что там происходит?
К тому же как Вы собираетесть реализовывать тесты BDD в связке с IDE?
Я бы пошел по такому пути:
Определился, нужен ли мне BDD, т.к. надеяться, что тестовая команда будет за меня тесты в необходимом формате писать, а я только библиотеку шагов дописывать не приходится. Соответственно для меня это была бы головная боль.
Да и где-то здесь уже было обсуждение BDD в целом. Для себя сделал выводы, что пока жизнь не заставит, смысла на данную методологию переходить нет.
После определения того, что мне нужно, сел бы за архитектуру фреймворка, выбора врапперов, необходимости создания собственных оберток и прочего. Как и где хранить тестовые данные. Нужно ли работать с БД и т.д. Так же рассмотрел бы очевидные варианты в виде того же Selenide (для этого, правда, пришлось бы писать на яве, а не на питоне).
Приступил бы к написанию тестов. (Раз Вы хотели использовать Selenium IDE, вопроса о разновидностях браузеров не стоит).
Спасибо за ответ.
У Selenium же есть возможности импортировать unittest и делать тест кейсы используя unittest
from selenium import unittest и поехали.
Пока буду запускать IDE тесты, то в это время найду время на более детальное изучение питона и вебдрайвера, чтобы потом попрощаться с IDE.
Про BDD тогда понял, возможно, на данный момент сильно рано об этом думать.
А посоветуйте выбрать из pytest, selenide, webium и других инструментов при условии, что мало опыта в программировании на python.
Уже написал Мише, спасибо! Есть Селенид для Питона, Яков Крамаренко показывал, как это делать, но там нужен хороший опыт в программировании, чтобы быстро себе помочь.
неравнозначный список.
pytest, unittest, nose, doctest - это модули Питона для написания юниттестов.
Эти модули хорошие тем, что позволяют описывать тексткейсы и формировать из них сьюты, а так же определенным образом их запускать, если нужно ( например, декорированные тесткейсы по скорости выполнения: выполнить только самые быстрые GUI тесты).
Selenium, seledine (обертка над selenium) и прочие - это уже средство автоматизации. Во всех примерах, в том числе и IDE, где генерация кода происходит и уже по сути сама создает бойлерплейт кусок юниттест-кода - это намек на то, что в автотестах де факто используются фреймворки изначально предназначенные для юнит-тестирования.
Если хотите получать человекочитаемые отчеты, то это не повод погружаться в BDD, можно посмотреть на allure, где описание в коде тест-кейсов и степов через декораторы позволит как результат получить .xml файл, который в свою очередь можно сгенерить в читаемый красивый html.
nose, и pytest хороши тем, что позволяют широкие возможности по запуску тестов. Я пользуюсь nosetests утилитой, которой передаю параметры запуска тестов, а сама утилита - один из шагов сборки продукта.
Сегодня на udemy.com заканчивается распродажа курсов. И так как раз есть два курса по robot framework и преподаватель пользуется pycharm, вообщем, спасибо за подсказку, уже смотрю курс.
Пожалуй соглашусь с dezikk, по поводу Robot. Если нужно сделать быстро и более или менее качественно, лучшего бесплатного инструмента вам не найти. К тому же в нем используется Python и есть поддержка BDD, keyword и data driven подходов. А по мере дописывания сторонних библиотек или написания своих, подучите и Python заодно
Якщо, мало досвіду, то краще найняти на кілька днів чи годин профі - щоб він виходячи із ситуації на проекті спроектував архітектуру тестів. Це буде дешевше - чим потім переписувати тести…
На самом деле не понимаю, зачем писать на питоне, если можно на пыхе, тем более когда есть codeception где можно писать и приемочные тесты.
А программисты умеют кодить на питоне?
У меня была ситуации, я начилнал наши проекты писать на java. Но приложение написано на пыхе, из отдела, кто пишет на java таковых не было. Поддерживать автотесты никто не смог бы, после моего ухода. Поэтому персел на пыху.
Тут нужно продумать и другое, а будет ли кто-то после Вашего ухода поддерживать автотесты на питоне?
З.Ы. codeception как раз удобный как BDD … ничего дополнительного скачивать и устанавливать не надо .
Шанс, что после ухода работника, код на java или python будет поддерживаться, а на php уйдет в небытие - намного больше. По крайней мере у нас в больнице.
Да все очень просто. Оставьте пхп веб-программистам. Шанс, что уважающий себя веб-программист на адекватном проекте сядет писать автотесты, стремиться к нулю. Это как попросить хирурга поработать патологоанатомом
При этом практически любой автотестер сегодня может (или сможет) писать на питоне.
Общаюсь с RoR разработчиками и для них feature-тестирование через автотесты - нормальное явление. Тесты они пишут сами - это естественный первоочередной шаг в нормальном TDD. Скорее уважающий себя разработчик сам должен понимать, что правильно оттестированный софт начинается с него самого. Почему я так считаю? Почитал неплохую книжку How Google Tests Software. Наверное, там все же уважающие себя вэб-программисты работают
testomat.io управление авто тестами
