Сообщений в теме: 37

[BoBuS]

Доброго времени суток.
Можно ли в selenium поставить выполнение тестов по расписанию? И как это можно реализовать?
Сейчас использую selenium ide, но понятно, что через него этого нельзя сделать. Как можно сделать через selenium rs?

[KaNoN]

Копайте в направлении Continuous Integration.
Если вы используете Selenium-RC, то скорее всего вам придется использовать какой-то тестовый движок для запуска тестов. Это может быть JUnit, TestNG, NUnit и т.п. в зависимости от используемого языка программирования.

Помимо этого практически для каждого языка программирования есть специальные движки, которые управляют сборкой проекта. Например, Ant (для Java), make (Perl, C/C++), rake (Ruby). С их помощью можно создать задачи для пакетного запуска определенной группы тестов.

И наконец, есть специальные инструменты для Continuous Integration, которые как раз позволяют запускать вышеуказанные задачи или по расписанию или при определенном событии (например, при чекине изменений). Из таких средств могу назвать Hudson, Cruise Control, Team City.

Более четко на этот вопрос можно будет ответить, если будет лучше известно, какой язык будет использоваться для разработки тестов.

[enki86]

BoBuS,
1. если у вас есть система непрерывной интеграции, такая, например, как СС (Cruise Control), вопрос не имеет смысла. Именно там после очередной сборки (или каких-то иных условий) прописываются триггеры запуска тестового сценария.
2. если системы непрерывной интеграции нет + вы не используете какую-либо оболочку над selenium, то имеет смысл использовать или средства языка программирования, который планируется использовать с RC, либо сторонние шедулеры, к примеру (Quartz - для java)

[BoBuS]

KaNoN, пишу на php

[adzynia]

KaNoN, пишу на php

Тогда используйте phpunit. Методы запуска тестов:
- батниками или sh скриптами(не очень хорошо);
- ant или phing(уже лучше);
- ставить Cruise Control и плагин к нему PhpUnderControl или Hudson;

[KaNoN]

KaNoN, пишу на php

Как уже сказали, можно использовать PHPUnit, его командную строку можно обернуть внутри какого-нибудь bat-файла.
Для наглядного вывода можно использовать какой-то из стандартных форматтеров (junit или html). Если используется junit форматтер, то для того же Hudson есть т.н. xUnit плагин, который хорошо парсит такие репорты.

Помимо этого, в PHPUnit есть еще возможность генерировать code coverage данные.

Также можете посмотреть в сторону Behat. Тоже интересная штука.

[BoBuS]

Всем спасибо. Посмотрю все импортные слова, что вы мне привели.

Если делать через phpunit, то как сделать тот же батник или sh ? плюс как вывести лог, что тест прошел нормально или же нет. Например открылась ли страница такая-то или же нет.

[stmark]

плюс как вывести лог, что тест прошел нормально или же нет. Например открылась ли страница такая-то или же нет.

PHPUnit создаёт xml с результатами, мерджим его в CC, а далее вроде как есть готовые решения для CC Dashboard, ну или можно оттянуться и самому наваять XSLT файлик, который создаст отдельную страницу с результатами прогонки тестов по вашему вкусу.

[LeshaL]

Тогда используйте phpunit. Методы запуска тестов:
- батниками или sh скриптами(не очень хорошо);
- ant или phing(уже лучше);
- ставить Cruise Control и плагин к нему PhpUnderControl или Hudson;

Почему? Аргументируйте, пожалуйста.
На мой взгляд, самое простое и дешевое решение, если надо запустить тесты в X часов Н минут - написать shell-скрипт и поставить задачу в крон. Разворачивать ради этого круиз контрол - не вижу смысла.И почему использование ант-а лучше shell скрипта?

[KaNoN]

Тогда используйте phpunit. Методы запуска тестов:
- батниками или sh скриптами(не очень хорошо);
- ant или phing(уже лучше);
- ставить Cruise Control и плагин к нему PhpUnderControl или Hudson;

Почему? Аргументируйте, пожалуйста.
На мой взгляд, самое простое и дешевое решение, если надо запустить тесты в X часов Н минут - написать shell-скрипт и поставить задачу в крон. Разворачивать ради этого круиз контрол - не вижу смысла.И почему использование ант-а лучше shell скрипта?

Ant действительно смотрится как-то не к месту. А разревнуть Cruise Control или Hudson удобно потому, что помимо основного функционала запуска тестов по расписанию там можно настроитькучу других задач. Например:
- автоматическая проверка синтаксиса при каждом чекине
- хранение истории сборок
- нотификация о результатах выполнения по e-mail
- Различные плагины для графического представления результатов выполнения тестов + различная статистика
и многое другое. В ряде случаев это весьма полезно.

[LeshaL]

Тогда используйте phpunit. Методы запуска тестов:
- батниками или sh скриптами(не очень хорошо);
- ant или phing(уже лучше);
- ставить Cruise Control и плагин к нему PhpUnderControl или Hudson;

Почему? Аргументируйте, пожалуйста.
На мой взгляд, самое простое и дешевое решение, если надо запустить тесты в X часов Н минут - написать shell-скрипт и поставить задачу в крон. Разворачивать ради этого круиз контрол - не вижу смысла.И почему использование ант-а лучше shell скрипта?

Ant действительно смотрится как-то не к месту. А разревнуть Cruise Control или Hudson удобно потому, что помимо основного функционала запуска тестов по расписанию там можно настроитькучу других задач. Например:
- автоматическая проверка синтаксиса при каждом чекине
- хранение истории сборок
- нотификация о результатах выполнения по e-mail
- Различные плагины для графического представления результатов выполнения тестов + различная статистика
и многое другое. В ряде случаев это весьма полезно.

Я знаю возможные плюсы разных CI. Но, для простой задачи - запустить что-то в определенное время - есть простое решение.
Интересно узнать почему это простое решение названо не очень хорошим.

[KaNoN]

Я знаю возможные плюсы разных CI. Но, для простой задачи - запустить что-то в определенное время - есть простое решение.
Интересно узнать почему это простое решение названо не очень хорошим.

Оно может быть не очень хорошим как раз потому, что запуск тестов по расписанию - это просто ключевая задача, но не единственная. Сам по себе запуск тестов по расписанию особого смысла не имеет. То есть тесты запускаются для чего-то, а не просто так. То есть нужны еще результаты,которые надо бы собрать, удобно разместить и отобразить в каком-то наглядном виде. То есть к этой простой задаче сами собой прирастут другие подзадачи, которые уж наверняка придется решать. Ну так почему бы сразу же не рассмотреть именно системы, которые это все могут заранее охватить? В противном случае есть риск потратить много лишнего времени на "наколенное творчество". Вот зачем такое?

[adzynia]

Тогда используйте phpunit. Методы запуска тестов:
- батниками или sh скриптами(не очень хорошо);
- ant или phing(уже лучше);
- ставить Cruise Control и плагин к нему PhpUnderControl или Hudson;

Почему? Аргументируйте, пожалуйста.
На мой взгляд, самое простое и дешевое решение, если надо запустить тесты в X часов Н минут - написать shell-скрипт и поставить задачу в крон. Разворачивать ради этого круиз контрол - не вижу смысла.И почему использование ант-а лучше shell скрипта?

Я раньше тоже думал, что ant не к месту. Но один раз столкнулся с проблемой. Когда тесты, которые запускаются при помощи bat файла, валятся по непонятной причине(если работать через selenium grid). Когда переписал все на ant, проблема отпала. Обсуждалось вот здесь.

[adzynia]

Я знаю возможные плюсы разных CI. Но, для простой задачи - запустить что-то в определенное время - есть простое решение.
Интересно узнать почему это простое решение названо не очень хорошим.

Оно может быть не очень хорошим как раз потому, что запуск тестов по расписанию - это просто ключевая задача, но не единственная. Сам по себе запуск тестов по расписанию особого смысла не имеет. То есть тесты запускаются для чего-то, а не просто так. То есть нужны еще результаты,которые надо бы собрать, удобно разместить и отобразить в каком-то наглядном виде. То есть к этой простой задаче сами собой прирастут другие подзадачи, которые уж наверняка придется решать. Ну так почему бы сразу же не рассмотреть именно системы, которые это все могут заранее охватить? В противном случае есть риск потратить много лишнего времени на "наколенное творчество". Вот зачем такое?

Полностью поддерживаю!

[OVA]

Оно может быть не очень хорошим как раз потому, что запуск тестов по расписанию - это просто ключевая задача, но не единственная. Сам по себе запуск тестов по расписанию особого смысла не имеет. То есть тесты запускаются для чего-то, а не просто так. То есть нужны еще результаты,которые надо бы собрать, удобно разместить и отобразить в каком-то наглядном виде. То есть к этой простой задаче сами собой прирастут другие подзадачи, которые уж наверняка придется решать. Ну так почему бы сразу же не рассмотреть именно системы, которые это все могут заранее охватить? В противном случае есть риск потратить много лишнего времени на "наколенное творчество". Вот зачем такое?

Так в том-то и дело что решение данной конкретной задачи через шедулер достаточно простое и особых усилий не требующее.

[KaNoN]

Оно может быть не очень хорошим как раз потому, что запуск тестов по расписанию - это просто ключевая задача, но не единственная. Сам по себе запуск тестов по расписанию особого смысла не имеет. То есть тесты запускаются для чего-то, а не просто так. То есть нужны еще результаты,которые надо бы собрать, удобно разместить и отобразить в каком-то наглядном виде. То есть к этой простой задаче сами собой прирастут другие подзадачи, которые уж наверняка придется решать. Ну так почему бы сразу же не рассмотреть именно системы, которые это все могут заранее охватить? В противном случае есть риск потратить много лишнего времени на "наколенное творчество". Вот зачем такое?

Так в том-то и дело что решение данной конкретной задачи через шедулер достаточно простое и особых усилий не требующее.

Возможно, я не очень четко объяснил, в чем соль. Решение через шедулер простое, но оно не дает нужного решения в полной мере, так как дополнительные задачи возникают только по ходу.

Запустить тесты мало. Для начала не помешало бы взять свежее обновление из версионки, чтобы оно автоматом подтягивало свежую версию файлов. То есть вот, задача выросла просто по ходу. Затем, было бы неплохо получить информацию о запуске и сделать так, чтобы выдались результаты, которые бы не затирались при новом запуске. Какой смысл запука тестов, если нет предварительной обработки результатов? Вот еще одна подзадача, которая возникла по ходу.

И наконец, на одной и той же машине может возникнуть необходимость запуска тестов на разных конфигурациях в разное время. Для того, чтобы это все делать централизовано, шедулера мало.

И к тому же полчаса, необходимые для установки и настройки того же Хадсона - тоже задача, не требующая особых усилий. И при этом ряд подзадач, которые возникают, уже автоматизированы. В том числе тот же самый шедулер.

Идея в том, что лучше сразу взять более общее решение, которое может охватить большинство подзадач, чем понемногу прикручивать свои велосипеды с костылями для решения таких же задач. То есть, лучше сразу взять решение, которое для нас работает.

То есть, не надо сосредотачиваться только на дне сегодняшнем, а еще бы неплохо было бы предусмотреть возможности развития решения на будущее.

[OVA]

Возможно, я не очень четко объяснил, в чем соль. Решение через шедулер простое, но оно не дает нужного решения в полной мере, так как дополнительные задачи возникают только по ходу.

Запустить тесты мало. Для начала не помешало бы взять свежее обновление из версионки, чтобы оно автоматом подтягивало свежую версию файлов. То есть вот, задача выросла просто по ходу. Затем, было бы неплохо получить информацию о запуске и сделать так, чтобы выдались результаты, которые бы не затирались при новом запуске. Какой смысл запука тестов, если нет предварительной обработки результатов? Вот еще одна подзадача, которая возникла по ходу.

И наконец, на одной и той же машине может возникнуть необходимость запуска тестов на разных конфигурациях в разное время. Для того, чтобы это все делать централизовано, шедулера мало.

И к тому же полчаса, необходимые для установки и настройки того же Хадсона - тоже задача, не требующая особых усилий. И при этом ряд подзадач, которые возникают, уже автоматизированы. В том числе тот же самый шедулер.

Идея в том, что лучше сразу взять более общее решение, которое может охватить большинство подзадач, чем понемногу прикручивать свои велосипеды с костылями для решения таких же задач. То есть, лучше сразу взять решение, которое для нас работает.

То есть, не надо сосредотачиваться только на дне сегодняшнем, а еще бы неплохо было бы предусмотреть возможности развития решения на будущее.

1. Ну для начала те же батники/шелл скриптики в ant/Nant и обратно переписать не сильно трудно, если писать их руками. Тем более почти все что вы написали делается из командной строки без особых затруднений. А их-то и будет дергать шедулер, которого тут более чем достаточно. Более того - практически всю ту же работу и даже больше вам придется проделать для того чтобы начать что-то пускать на том же Хадсоне.

2. Опять же - кто вам сказал что обязательно понадобится все что вы написали? Это частные случаи. Говорить что одно решение лучше другого потому что в нравящемся вам частном случае оно действительно лучше по меньшей мере странно. Особенно когда частный случай является расширением изначальной задачи.

Идея про общее решение плоха тем, что это больше времени/сил и не всегда это общее решение нужно. Есть задачи которые не растут. Есть задачи для которых не нужен и никогда не понадобится Хадсон. Есть производственная необходимость и так далее. Это конечно круто что вы убьете лишние рабочие часы на то чтобы сделать круто и с заделом на будущее которое, возможно, никогда не наступит (причин море, можно начать с банального отсутствия ресурсов), но это пустая трата времени.

Мне вообще вся эта логика которую вы пишите напоминает некоторых разработчиков, которые хотят сделать как лучше, а делают как всегда + дедлайн опять ушел мимо.

[BoBuS]

Что-т никак не сяду попробовать инструменты, которые вы написали тут.
Да, задачу ставил простую, просто поставить в расписание один тест. Но писав в попыхах, совершенно не подумал про вывод результатов и т.д. что вы тут написали.
На выходных постораюсь поставить CC и поковыряться. Если будут вопросы отпишу в эту ветку.

OVA, как я понимаю, что KaNoN говорил про планы так скажем на будущие. А будущие может быть разным, мне было полезно почитать, то что вы тут отписывали. Спасибо.

[KaNoN]

1. Ну для начала те же батники/шелл скриптики в ant/Nant и обратно переписать не сильно трудно, если писать их руками. Тем более почти все что вы написали делается из командной строки без особых затруднений. А их-то и будет дергать шедулер, которого тут более чем достаточно. Более того - практически всю ту же работу и даже больше вам придется проделать для того чтобы начать что-то пускать на том же Хадсоне.

Шедулер не собирает результаты. Шедулер не вытянет последние апдейты и не подготовит рабочую область. Явное обращение к версионке из командной строки - это мега-костыль. И шедулер не сообщит вам, успешно всё прошло или нет.

2. Опять же - кто вам сказал что обязательно понадобится все что вы написали? Это частные случаи. Говорить что одно решение лучше другого потому что в нравящемся вам частном случае оно действительно лучше по меньшей мере странно. Особенно когда частный случай является расширением изначальной задачи.

Что из всего перечисленного частный случай? Тесты запускаются, чтобы проверить некоторый функционал. Поскольку тестируемое приложение со временем развивается и меняется, то тесты всегда надо держать в актуальном состоянии и использовать именно актуальные тесты. И тесты должны выдавать вполне конкретные результаты, которые надо бы как-то обработать. Что из этого является частным случаем?

Идея про общее решение плоха тем, что это больше времени/сил и не всегда это общее решение нужно. Есть задачи которые не растут. Есть задачи для которых не нужен и никогда не понадобится Хадсон. Есть производственная необходимость и так далее. Это конечно круто что вы убьете лишние рабочие часы на то чтобы сделать круто и с заделом на будущее которое, возможно, никогда не наступит (причин море, можно начать с банального отсутствия ресурсов), но это пустая трата времени.

Мне вообще вся эта логика которую вы пишите напоминает некоторых разработчиков, которые хотят сделать как лучше, а делают как всегда + дедлайн опять ушел мимо.

Хадсон полностью настраивается полчаса. Максимум час. Это если включить время инсталляции + настройку всех плагинов + полную пристрелку всего решения. Причем это делается один раз. Не особо похоже на убийство времени. Вы больше времени убьете, если все-таки окажется, что эти все дополнительные подзадачи надо все-таки как-то сделать (а уж наверняка понадобится). И со временем больше всего усилий будет уходить на интеграцию с существующими решениями.

И вот отдельное решение подзадач одной комплексной задачи впоследствии вырастает в самодельные кривые решения, в которых костыли на воркэраундах и которые просто никуда не переносятся.

[KaNoN]

Что-т никак не сяду попробовать инструменты, которые вы написали тут.
Да, задачу ставил простую, просто поставить в расписание один тест. Но писав в попыхах, совершенно не подумал про вывод результатов и т.д. что вы тут написали.

Вот то, о чем я писал. Одна задача цепляет другие. И это вполне нормально. Безусловно, готовить одно решение на все случаи жизни не имеет смысла, но вот позаботиться об основных вещах все-таки надо.