Покрываем проект smoke-тестами, пока он не сгорел

[mkevac]

Шутки отличные! Спасибо!

[NIKOSV]

Это не шутки, это реальная жизнь, к сожалению. Некоторые вот вообще тесты не пишут, потому что «их нужно поддерживать».

[jced]

Мне почему-то показалось, что это статья преимущественно мануал по cUrl для новичков.
И, возможно, есть смысл вместо

isset($params[‘headers’]) && $params[‘headers’]

использовать

!empty($params[‘headers’])

?

[nizkopal]

Я скорее старался рассказать о своем опыте создания определенного вида тестов, в основе которых, как Вы верно заметили, лежит cURL. Я написал о том, зачем эти тесты нужны и как их стоит использовать, с какими сложностями можно столкнуться и как я их решил для себя. Это чуть более готовый рецепт, чем мануал. :)

По поводу empty. В самом начале, когда метод только создавался, для какого-то параметра было удобнее использовать isset, но я не помню для какого, к сожалению. Возможно follow_location был в общем списке параметров и там проверка выглядела как только isset, без второго условия через &&. В итоге остальные тоже проверялись через isset. В целом Ваш код будет работать верно для моего примера и выглядит локанично, спасибо!

[iwex]

Можно при помощи CSS попытаться разыскать пропавший элемент

Немного не коректно

[nizkopal]

Пожалуй. Имелось в виду «при помощи CSS-локатора». Спасибо.

[Yeah]

Почему cURL, а не Symfony Crawler? Не пробовали ли Codeception? Если нет, то почему? Если да, то как оно?

[nizkopal]

Добрый день.
В зачаточном состоянии наши тесты существуют уже очень давно, тогда Codeception еще не было или он не был популярен. Использовали уже имеющийся для unit-тестов phpunit. На нем же мы сейчас запускаем selenium-тесты, так что выносить smoke-тесты из списка использующих phpunit нет смысла.

[xotey83]

Спрашиваю просто из интереса: а вы рассматривали такой инструмент: Codeception (http://codeception.com/)?

[nizkopal]

Для решения описанной задачи не рассматривали — ответил выше.

[nizkopal]

Изначально мы выбирали CI для более сложных целей, чем просто запуск тестов: Teamcity используется у нас для сборки демонов и мобильных приложений, и в этих сборках были важны разные функции, вроде шаблонов для конфигураций. Начинали мы с Jenkins, но из чисто субъективных соображений (скорость, которая казалась хуже, чем в Teamcity, внешний вид и сложность/количество настроек) мы перешли на Teamcity. Мы подумываем о том, чтобы посмотреть на альтернативы, возможно, даже выпустим статью с обзором, если наберется достаточно информации.
Было бы интересно услышать о Вашем опыте. :)

[slayerhabr]

Из статьи сделал один вывод — какое счастье иметь rspec и capybar'у

[nizkopal]

Неконструктивный комментарий.

Если он означает: "почему вы не использовали rspec и capybar?", то я уже написал об этом. У нас изначально проект на php и unit-тесты используют phpunit. Не имело смысла писать тесты на другом языке и использовать другую пускалку.
К тому же мы покрываем функциональными тестами только ту фичу, которая уже на продакшене. У нас очень гибкая система АБ-тестирования, мой коллега о ней рассказывает тут. Мы редка покрываем фичи, которые не прошли АБ-тестирование. Подход BDD нам не очень подойдет.

Если он означает: "а я программирую на ruby", то я рад. :)

[slayerhabr]

Он означает лишь то, что означает. )
Конкретнее — личное оценочное мнение — что Ваши тесты из середины 2000х годов.
Жутко не удобные и слишком «шумные»
Я даже вспомнил libcurl — лет 12 назад писал на C++ с его использованием.

[nizkopal]

Спасибо за уточнение. :)