Комментарии 15
Почему бы хотябы так не сделать, если прям именно такие версии нужны (совсем не понял про завязку на phpunit 5.3)?
{
"require-dev": {
"phpunit/phpunit": "5.3.*",
"facebook/webdriver": "1.5.*"
}
}
С легаси тестами все понятно, но если поднимать все с нуля с Selenium, то почему не на Codeception? В основе тот же phpunit, вплоть до того, что тесты на phpunit работают под Codeception — но там тот же WebDriver уже прикручен и обвешан хелперами, что экономит кучу времени. HTML source и скриншоты при ошибках тоже сохраняются. Также не совсем понятна причина отказа от CI — тот же Jenkins очень удобно пинать из BitBucket по триггерам (например, на каждый pull request), но это может оказаться вопросом бизнес-необходимости.
P.S. При желании весь тестовый стек для Codeception, включая Selenium head, поднимается за час в виде кластера контейнеров на Docker. Результатом оказывается портативные и легко версионируемые тесты, которые можно запускать одновременно в нескольких копиях, если есть такое желание.
P.S. При желании весь тестовый стек для Codeception, включая Selenium head, поднимается за час в виде кластера контейнеров на Docker. Результатом оказывается портативные и легко версионируемые тесты, которые можно запускать одновременно в нескольких копиях, если есть такое желание.
Привет. Спасибо за Ваш комментарий.
Вы, безусловно, правы насчет Codeception. Это отличный фреймворк для развертывания тестов. Но я преследовал задачу сделать эти тесты максимально похожими по архитектуре на наши основные тесты, поскольку в долгосрочной перспективе они могли обрести общую кодовую базу. К тому же поддерживать два проекта, написанных в одном стиле, на порядок удобнее.
Я был уверен, что кто-то обязательно подумает про Codeception и потому добавил:
Но меня это не спасло. :)
Что касается отказа от CI — там все просто. Код проекта так или иначе находился в другом окружении, нежели тесты, следовательно, тестирование было по принципу black-бокса. CI не решил бы проблему отсутствия триггера, все равно пришлось бы лепить свой воркэраунт. А причастным к проекту людям первое время отчет было удобнее получать в виде писем. Со временем проект подрос и сейчас все крутится на том же ТимСити, где и остальные тесты.
Вы, безусловно, правы насчет Codeception. Это отличный фреймворк для развертывания тестов. Но я преследовал задачу сделать эти тесты максимально похожими по архитектуре на наши основные тесты, поскольку в долгосрочной перспективе они могли обрести общую кодовую базу. К тому же поддерживать два проекта, написанных в одном стиле, на порядок удобнее.
Я был уверен, что кто-то обязательно подумает про Codeception и потому добавил:
Поскольку задача была срочная, я решил не экспериментировать с технологиями.
Но меня это не спасло. :)
Что касается отказа от CI — там все просто. Код проекта так или иначе находился в другом окружении, нежели тесты, следовательно, тестирование было по принципу black-бокса. CI не решил бы проблему отсутствия триггера, все равно пришлось бы лепить свой воркэраунт. А причастным к проекту людям первое время отчет было удобнее получать в виде писем. Со временем проект подрос и сейчас все крутится на том же ТимСити, где и остальные тесты.
Всё понятно, спасибо. Я спросил потому, что за время работы с Codeception vs. phpunit не увидел чего-то такого, что шокировало бы меня разницей в подходах. Кроме того, phpunit тесты отлично импортируются напрямую в Codeception. Но тут, видимо, были внутренние причины так не делать. Спасибо за уточнения!
Вы бы сэкономили гораздо больше времени если бы взяли Codeception :)
PHPUnit + WebDriver конечно надежная связка, но изначально было понятно, что без костылей там не обойдется.
Собственно почему Codeception смог бы быстрее решить задачу:
- сохранение артефактов и отчеты по умолчанию
- возможность запуска тестов с разной конфигурацией из коробки
- из коробки почту не шлет, но есть екстеншн который это делает https://github.com/Codeception/Notifier (его скорее всего не хватит и потому достаточно просто можно всё расширить через екстеншны).
А чтобы это не казалось рекламой — закончу небольшой жизой. И Codeception и PHPUnit это сверхтяжелые фреймворки в которые порой бывает сложно куда-то впихнуться, в особенности когда нужно сделать что-то эдакое. И то и то надо изучать, а потом смотреть. Codeception в плане расширения предоставляет гораздо больше механизмов чтобы сделать всё что нужно и сделать это не костылями, а елегантно (элегантными костылями хе-хе). Да и API для PHPUnit по сути не обновлялся последние 10 лет...
Хм. Интересное дополнение, спасибо.
Мой опыт работы с Codeception маловат. Не потому, что я имею что-то против него. Просто у нас сейчас свой фреймворк, основанный на версии Facebook Webdriver библиотеке шестилетней давности. И запускаем мы эти тесты на PHPUnit, вокруг которого у нас существует множество своих решений, обвязок и прочих ништяков.
Напомню, что задачка была срочно и «я решил не экспериментировать с технологиями». Однако я все больше склоняюсь к тому, чтобы повнимательнее поизучать Codeception либо в свободное время, либо на проекте с более свободным графиком.
В любом случае еще раз спасибо за Ваш комментарий. :)
Мой опыт работы с Codeception маловат. Не потому, что я имею что-то против него. Просто у нас сейчас свой фреймворк, основанный на версии Facebook Webdriver библиотеке шестилетней давности. И запускаем мы эти тесты на PHPUnit, вокруг которого у нас существует множество своих решений, обвязок и прочих ништяков.
Напомню, что задачка была срочно и «я решил не экспериментировать с технологиями». Однако я все больше склоняюсь к тому, чтобы повнимательнее поизучать Codeception либо в свободное время, либо на проекте с более свободным графиком.
В любом случае еще раз спасибо за Ваш комментарий. :)
Берем codeception фреймворк. Минута на установку, еще минута на бутстрап проекта и 5 минут на конфигурацию в yml (если новичок, то пол часа на прочтение getting started). Получаем готовый к использованию сетап с понятным интересом, соединенный с селениумом, прекрасными html репортами, включая скриншоты браузера, и всеми нужными ивентами (before/after step, before/after test, before/after suite). Остается дописать свое расширение которое будет слать репорт по почте. Ну и крон можно по тому же принципу что и в статье реализовать.
Спасибо за комментарий.
В целом про Codeception я ответил выше. Из Вашего же описания выходит, что, установив Codeception, я бы все равно был бы вынужден писать всю ту же логику. Просто сэкономил бы время на описании tearDown, setUp и onNotSuccessful тест. Как мне кажется, это не так принципиально. :)
Будет здорово, если Вы напишете свою статью про Ваш любимый стек. Я с интересом ее почитаю.
В целом про Codeception я ответил выше. Из Вашего же описания выходит, что, установив Codeception, я бы все равно был бы вынужден писать всю ту же логику. Просто сэкономил бы время на описании tearDown, setUp и onNotSuccessful тест. Как мне кажется, это не так принципиально. :)
Будет здорово, если Вы напишете свою статью про Ваш любимый стек. Я с интересом ее почитаю.
Все же абсолютно любой CI-сервер решает проблемы с доставкой репорта, триггер в jenkins по изменению чего-либо на сайте настраивается на раз (если я ничего не забыл, пользовался этой фичей раз в жизни), скрипт в кроне с выкачиванием из git тоже становится не нужен.
У вас, в принципе, тоже не сложно, но не понятно — в чем проблема была взять готовое :/
У вас, в принципе, тоже не сложно, но не понятно — в чем проблема была взять готовое :/
Привет.
Не очень понял Ваш комментарий. Скрипт в cron ничего не качал с git. Он только по http ходил по специальному адресу, где отдавался последний хеш-комит. Более того, в окружении тестов не было никакого доступа к репозиторию приложения. Ни доступов к его git, ни к исходникам, вообще ничего. CI не решил бы проблему триггерить что-либо по изменению в коде, к которому у него нет доступа.
У меня получилось описать суть проблемы более понятно?
Не очень понял Ваш комментарий. Скрипт в cron ничего не качал с git. Он только по http ходил по специальному адресу, где отдавался последний хеш-комит. Более того, в окружении тестов не было никакого доступа к репозиторию приложения. Ни доступов к его git, ни к исходникам, вообще ничего. CI не решил бы проблему триггерить что-либо по изменению в коде, к которому у него нет доступа.
У меня получилось описать суть проблемы более понятно?
Коллега, я суть проблемы понял верно. Вот как бы я решил эту задачу без кастома на баше. Вроде, получается быстрее, удобнее и не на много более накладно по ресурсам — поэтому мне не понятно, откуда у вас такое странное требование — обойтись без системы CI.
Билд-триггер, который делает то, что вам нужно: plugins.jenkins.io/urltrigger (Считается md5 содержимого ответа, если оно изменилось с прошлого раза — стартует билд. Так же поддерживает триггер по заголовку last modified)
Про гит я говорил в контексте того, что не нужно вытягивать тесты — то есть скрипт с git pull не нужен (CI сам вытянет). Что вы тестируете черный ящик я понял.
Оповещение на мейл — вообще стандартная фича, а если стандартного не хватит — есть целая охапка на любой вкус.
Остается только указать этому хозяйству, как ваши тесты запустить и откуда потом взять репорт, чтобы выслать на почту. Уверен, что в других CI-системах дела обстоят примерно так же.
Билд-триггер, который делает то, что вам нужно: plugins.jenkins.io/urltrigger (Считается md5 содержимого ответа, если оно изменилось с прошлого раза — стартует билд. Так же поддерживает триггер по заголовку last modified)
Про гит я говорил в контексте того, что не нужно вытягивать тесты — то есть скрипт с git pull не нужен (CI сам вытянет). Что вы тестируете черный ящик я понял.
Оповещение на мейл — вообще стандартная фича, а если стандартного не хватит — есть целая охапка на любой вкус.
Остается только указать этому хозяйству, как ваши тесты запустить и откуда потом взять репорт, чтобы выслать на почту. Уверен, что в других CI-системах дела обстоят примерно так же.
Хм, интересно. Значит я Вас не так понял.
Честно говоря, никогда не слышал про триггеры по изменению содержимого ответа по URL. Это открытие для меня. Вообще, мы по большей части все тесты в ТимСити гоняем, на Дженкинс бы я точно не решился ради одного единого проекта. Ради интереса посмотрю, есть ли аналогичный плагин для ТимСити. Главное, чтобы история запусков не выглядела, как 10 запусков со статусом Success (или что он там пишет, если ответ не изменился), потом один нормальный, потом еще 15 Success и так далее. :)
Но в целом, для меня написать пару строк кода на bash и развернуть CI задачислегка разного масштаба. Возможно, дело только во мне и в том, что на второе рука у меня не набита.
Еще раз спасибо за комментарий, есть над чем подумать. :)
Честно говоря, никогда не слышал про триггеры по изменению содержимого ответа по URL. Это открытие для меня. Вообще, мы по большей части все тесты в ТимСити гоняем, на Дженкинс бы я точно не решился ради одного единого проекта. Ради интереса посмотрю, есть ли аналогичный плагин для ТимСити. Главное, чтобы история запусков не выглядела, как 10 запусков со статусом Success (или что он там пишет, если ответ не изменился), потом один нормальный, потом еще 15 Success и так далее. :)
Но в целом, для меня написать пару строк кода на bash и развернуть CI задачи
Еще раз спасибо за комментарий, есть над чем подумать. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разворачиваем автоматизацию за пару часов: PHPUnit, Selenium, Composer