Я вобщем новичек в автоматизации, так сложились обстоятельства что на данный момент разбираюсь с реализацией тестирования используя Ruby + Cucumber (была проблема http://automated-testing.info/forum/webdriverjs, но подключив здравый смысл удалось переубедить команду на более популярное решение)
Теперь собственно вопрос: А есть ли среди Вас кто-либо, кто практиковал и/или практикует тестирование Веб апликейшенов используя вышеупомянутые язык и инструмент? Если да, то поделитесь пожалуйста какими Вы еще тулами пользуетесь, и в каких конкретно целях, то бишь почему, ну и может источники какие надо прочесть-изучить, чтоб самостоятельно разобраться в проблемах. Вобщем буду очень рад если удасться найти добровольца(-цев) который периодически сможет находить время для ответов на мои возникающие вопросы:)
Моя основная задача это написание фич со степами ("огуречные" файлы), которые впоследствии будут гонятся по мере выпуска новых билдов, на, собственно, билд сервере. Что для всего этого нужно знать и уметь? + Какие тулы задействовать? Раньше с билд серверами не работал, к сожалению.
Сразу хочу сказать, что Cucumber – это инструмент хороший, но есть проблема в том, что и использовать его нужно правильно. К сожалению, чтобы понять, как делать это «правильно», нужно встать на огромное количество граблей.
И, сразу скажу, конкретно с Cucumber и Ruby я не работал, но все же, немного «в теме».
Есть книга, которая может помочь, и пролистав которую, я считаю полезной:
Я слышал и читал мнения и других людей, которые говорили, что активно и успешно используют Cucumber. Но, для веб-автоматизации они не ограничиваются одним этим инструментов, а используют и RSpec , выбирая тот инструмент, который будет более удобным в конкретной ситуации.
Capybara – это очень простая библиотека, надстройка над Webdriver, делающая код проще и понятней. Содержит около 20-ти команд, но эти команды делают код намного проще.
Вот, например, там уже есть расширения для более удобной работы с табилцами, выпадающими списками, можно использовать поиск внутри блока, например:
within("//form[@id='session']") do
fill_in 'Login', :with => 'user@example.com'
fill_in 'Password', :with => 'password'
end
И, совершенно верно, этот инструмент можно использовать как в интеграции с Cucumber так и RSpec.
А что конкретно интересует по Cucumber? :) У меня на работе Rails-проект и, следовательно, для браузерных тестов используется связка Cucumber + Capybara + Webkit. В процессе обучения хватало http://cukes.info/ и Гугла. Возможно, смогу чем-то помочь.
Интересно а Cucumber Вы для ЮАй тестирования используете или для Юнит тестов и для BDD?
И еще (за это время много поменялось и честно говоря Cucumber'ом остался не особо доволен), почему не используете RSpec?
Я его изучил, мне очень понравилось, попрактиковал, теперь все ранее написанные тесты под Cucumber "перевожу" под Rspec. По сравнению с Огурцом у него очень много положительных моментов
плюс предлагаю прочесть интересную на эту тему статью http://www.jackkinsella.ie/2011/09/26/why-bother-with-cucumber-testing.html
Для всех заинтересованных - уже пару месяцев (не срок конечно) автоматизирую ГУИ нескольких небольших веб проектов используя Rspec+Capybara (на руби). Очень буду рад обменяться опытом, и если кому будет нужно, помочь-подсказать;)
Unit-тесты отдельно - там RSpec. Cucumber используем для BDD.
Почему именно Cucumber? Так сложилось исторически. Дело в том, что в одной из первых версиий cucumber-rails (точно не скажу в какой, а выяснять влом) была сделана такая вещь как генерация web_steps.rb при установке. Следовательно разработчик (в команде долгое время не было тестировщика) сразу получал в свои руки инструмент, который позволял писать тесты вроде таких:
Scenario: Successful login
Given a user "Aslak" with password "xyz"
And I am on the login page
And I fill in "User name" with "Aslak"
And I fill in "Password" with "xyz"
When I press "Log in"
Then I should see "Welcome, Aslak"
Выглядят они немного ужасно и как-бы это не совсем по BDD. Но инструмент есть и им можно пользоваться. Так люди стали писать такие тесты низкого качества. Год назад эта автогенерация была выкинута с целью побудить людей писать тесты вида:
Scenario: User is greeted upon login
Given the user "Aslak" has an account
When he logs in
Then he should see "Welcome, Aslak"
Подробнее можно почитать или в описании ишью на Гитхабе (сссылка чуть выше) или в этой статье. Также в конце статьи даны несколько интересных ссылок, на которые тоже стоит обратить внимание. В частности там же преведена ссылка на Why Bother With Cucumber Testing? , которую советуете почитать вы. Мы постепенно переписываем свои тесты. К сожалению, их накопилось много и времени особо нет переделать их сразу.Если резюмировать, то при правильном использовании, Кукумбер - гораздо лучший инструмент, чем RSpec. И более удобен он тогда, когда тесты будут писать-читать люди, не владеющие языком программирования - заказчики, бизнес-аналитики, QA-отдел. Хотя в целом связки RSpec + Capybara бывает достаточно и она покроет все ваши потребности.
У меня с Кукумбером возникли проблемы, когда нужно было заавтоматизировать многошаговый воркфлоу, плюс на каждом шаге нужно было сделать много проверок на разные типы валидации, разные способы закрытия самого воркфлоу, и способы переключения между самими степами. Следуя принципам "один сценарий - одна проверка" получалось порядка четырех десятков сценариев в одном фича-файле, плюс к ним добавлялись громоздкие вспомогательные методы, которые каждый следующий раз "подходили" к пункту назначения в пределах многошагового воркфлоу'а для проведения очередных проверок. В добавок ко всему меня очень смущал второй файл step-definitions, который по факту ближе к середине написания такого теста превращался в такую бесформенную ерунду в которой ориентироваться без магии РубиМайна заключенной в сочетании клавиш Ctrl+B, было невозможно, а поддерживать при каких либо изменениях и того хуже.
РСпек очень радует возможностью организации сценариев в группы, и что самое интересное вкладывать эти группы друг в друга, что очень полезно, еще мне нравится отсутствие необходимости поддерживать синхронизацию и правильное "сотрудничество" двух файлов, так как в случае с РСпек - он один, а параметр "--format documentation" сопровождающий строку запускающую "спеки" генерит файлик по структуре не менее удобный для чтения и использования для BDD.
И да, к сожалению (или к счастью) мои тесты, никто кроме меня, читать и писать не будет:(
testomat.io управление авто тестами