Тестирование → Распараллеливание тестов или одна голова — хорошо, а две головы — лучше
В какой-то момент, если долго и усердно стараться сохранять покрытие тестами не меньше 80% кода, прогон полного комплекта тестов начнет занимать больше времени, чем уходит на перекур и на прочтение новых статей хабра. В свою очередь это приводит к тому, что полный комплект (suite) будет запускаться все реже и реже. Hudson начнет сообщать о сломанных билдах, а дальше сработает эффект разбитого окна и сломанный билд станет нормой.
Можно стараться запускать полный прогон перед каждым коммитом. Но затраты времени на кино в виде пробегающих по экрану фич cucumberа, а также выход из потока снизят эффективность разработчиков в разы.
В одном из наших проектов, в который согласно записям redmine вложено около 400 часов работы нашего коллектива ситуация с тестами до распараллеливания выглядела так (пару дней назад):
18 минут!!!
За это время разработчик может сварить кофе, выкурить сигарету, сходит в туалет, ущипнуть за попу симпатичную коллегу и успеть посмотреть последние 3 минуты «матрицы» на экране. Если требовать от него чтобы полный прогон запускался перед каждым коммитом, то он только и будет делать что смотреть «матрицу» ищипать попы пить кофе.
Но анализ загрузки процессора при прогоне показывает, что в работе участвует только лишь одно ядро независимо от того, сколько их всего есть. Как говорит пословица, лучше день потерять, а потом за пять минут долететь. Порыскав в гугле мы нашли гем parallel_tests. Теперь мы не с такой завистью будем смотреть на erlang группу, которые могут спокойно распараллелить свои тесты на кластер арендованных облачных машин в Selectel.
Можно стараться запускать полный прогон перед каждым коммитом. Но затраты времени на кино в виде пробегающих по экрану фич cucumberа, а также выход из потока снизят эффективность разработчиков в разы.
В одном из наших проектов, в который согласно записям redmine вложено около 400 часов работы нашего коллектива ситуация с тестами до распараллеливания выглядела так (пару дней назад):
151 scenarios (151 passed)
3997 steps (3997 passed)
17m49.257s
18 минут!!!
За это время разработчик может сварить кофе, выкурить сигарету, сходит в туалет, ущипнуть за попу симпатичную коллегу и успеть посмотреть последние 3 минуты «матрицы» на экране. Если требовать от него чтобы полный прогон запускался перед каждым коммитом, то он только и будет делать что смотреть «матрицу» и
Но анализ загрузки процессора при прогоне показывает, что в работе участвует только лишь одно ядро независимо от того, сколько их всего есть. Как говорит пословица, лучше день потерять, а потом за пять минут долететь. Порыскав в гугле мы нашли гем parallel_tests. Теперь мы не с такой завистью будем смотреть на erlang группу, которые могут спокойно распараллелить свои тесты на кластер арендованных облачных машин в Selectel.
Тестирование → Консольный cucumber и capybara при помощи Selenium и Hudson
В наши дни разработчики ПО не могут прожить без их любимых тестовых фреймворков. Но вот чего разрабочики не хотят — так это обеспечивать постоянный запуск этих тестов. Также, команды разработчиков не хотят тратить время на доведение результатов теста до всех.
Появляется все больше и больше полезных приложений, библиотек и плагинов, которые частично облегчают головную боль, возникающую в ходе попыток сделать тесты полезными для всей команды. Примерами прекрасных инструментов, которые есть в нашем распоряжении, могут быть Hudson для непрерывной интеграции, Cucumber для интеграционных тестов и Selenium для автоматизированного тестирования веб-приложений в реальном браузере. Но организация совместной работы всего этого требует все больше и больше настроек и конфигураций на сборочном сервере.
Наша цель — задокументировать шаги, требуемые для преодоления встречающихся препятствий на пути к запуску полного набора тестов Cucumber со сценариями на Selenium на сборочном сервере Hudson.
Появляется все больше и больше полезных приложений, библиотек и плагинов, которые частично облегчают головную боль, возникающую в ходе попыток сделать тесты полезными для всей команды. Примерами прекрасных инструментов, которые есть в нашем распоряжении, могут быть Hudson для непрерывной интеграции, Cucumber для интеграционных тестов и Selenium для автоматизированного тестирования веб-приложений в реальном браузере. Но организация совместной работы всего этого требует все больше и больше настроек и конфигураций на сборочном сервере.
Наша цель — задокументировать шаги, требуемые для преодоления встречающихся препятствий на пути к запуску полного набора тестов Cucumber со сценариями на Selenium на сборочном сервере Hudson.
Веб-разработка → Rails: Хватит отмазываться, начинаем BDD-ить! из песочницы
Кто здесь?
Когда речь заходит о тестировании существующего продукта, а тем более о разработке чего-то нового на основе изначального написания сценариев использования, различных спецификаций и тестов, то частенько можно слышать подобные вещи:
11:24:21 PM Michael: ну хз, надо пробовать 11:24:24 PM Michael: наверное так лучше 11:24:27 PM Michael: даже я думаю наверняка 11:24:36 PM Michael: но пока меня че-то останавливает 11:24:38 PM Michael: лень наверное :)
Знакомо? «Не хочется разбираться? Нет времени?» Тогда читаем дальше. В статье расскажу, как настроить свое любимое рельсовое окружении на разработку с подходом BDD и начать новую жизнь (опционально).
PHP → PHP + BDD = Behat, или сказ о чудо-библиотеке из песочницы
Каждый, кто всерьез занимался разработкой на Ruby, знает про замечательный гем Cucumber. Вкратце — это библиотека для автоматизированного тестирования, заточенная под BDD. Подробнее можно почитать в топике хабраюзера dapi, а еще лучше посмотреть подкаст от Райна Бэйтса. Основная прелесть «огурца» состоит в том, что он позволяет писать тесты на понятном человеку языке, и даже не обязательно английском. Выглядит это так:
Благодаря Cucumber я подсел на BDD на рельсах. Но вот на PHP, с которым приходится работать основную часть времени, отношения с BDD как-то не сложились. И в первую очередь из-за отсутствия достойного инструментария. Но однажды судьба завела меня на страницу библиотеки Behat (написанной, кстати говоря, хабраюзером everzet). И на меня свалилось счастье…
Feature: Addition
In order to avoid silly mistakes
As a math idiot
I want to be told the sum of two numbers
Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then The result should be 120 on the scree
Благодаря Cucumber я подсел на BDD на рельсах. Но вот на PHP, с которым приходится работать основную часть времени, отношения с BDD как-то не сложились. И в первую очередь из-за отсутствия достойного инструментария. Но однажды судьба завела меня на страницу библиотеки Behat (написанной, кстати говоря, хабраюзером everzet). И на меня свалилось счастье…
Ruby → BDD с помощью Cucumber
Если вы привыкли сначала писать код, а потом его тестировать, то с BDD такой подход совсем не уместен. Сила BDD в том, что он помогает вести разработку начиная со стадии оформления ТЗ. Для BDD это список свойств (фич), который уместно писать вместе с заказчиком.
Но самое главное, что по этому же списку происходит автоматическое тестирование проекта. Инструмент тестирования (в нашем случае это Cucumber) методично пройдет по вашему перечню и дотошно проверит реализацию каждой фичи.
Но самое главное, что по этому же списку происходит автоматическое тестирование проекта. Инструмент тестирования (в нашем случае это Cucumber) методично пройдет по вашему перечню и дотошно проверит реализацию каждой фичи.