Comments 16
Шутки отличные! Спасибо!
+4
Мне почему-то показалось, что это статья преимущественно мануал по cUrl для новичков.
И, возможно, есть смысл вместо
И, возможно, есть смысл вместо
isset($params[‘headers’]) && $params[‘headers’]
использовать !empty($params[‘headers’])
?0
Я скорее старался рассказать о своем опыте создания определенного вида тестов, в основе которых, как Вы верно заметили, лежит cURL. Я написал о том, зачем эти тесты нужны и как их стоит использовать, с какими сложностями можно столкнуться и как я их решил для себя. Это чуть более готовый рецепт, чем мануал. :)
По поводу empty. В самом начале, когда метод только создавался, для какого-то параметра было удобнее использовать isset, но я не помню для какого, к сожалению. Возможно follow_location был в общем списке параметров и там проверка выглядела как только isset, без второго условия через &&. В итоге остальные тоже проверялись через isset. В целом Ваш код будет работать верно для моего примера и выглядит локанично, спасибо!
По поводу empty. В самом начале, когда метод только создавался, для какого-то параметра было удобнее использовать isset, но я не помню для какого, к сожалению. Возможно follow_location был в общем списке параметров и там проверка выглядела как только isset, без второго условия через &&. В итоге остальные тоже проверялись через isset. В целом Ваш код будет работать верно для моего примера и выглядит локанично, спасибо!
0
Можно при помощи CSS попытаться разыскать пропавший элемент
Немного не коректно
0
Почему cURL, а не Symfony Crawler? Не пробовали ли Codeception? Если нет, то почему? Если да, то как оно?
0
Добрый день.
В зачаточном состоянии наши тесты существуют уже очень давно, тогда Codeception еще не было или он не был популярен. Использовали уже имеющийся для unit-тестов phpunit. На нем же мы сейчас запускаем selenium-тесты, так что выносить smoke-тесты из списка использующих phpunit нет смысла.
В зачаточном состоянии наши тесты существуют уже очень давно, тогда Codeception еще не было или он не был популярен. Использовали уже имеющийся для unit-тестов phpunit. На нем же мы сейчас запускаем selenium-тесты, так что выносить smoke-тесты из списка использующих phpunit нет смысла.
0
Спрашиваю просто из интереса: а вы рассматривали такой инструмент: Codeception (http://codeception.com/)?
0
UFO just landed and posted this here
Изначально мы выбирали CI для более сложных целей, чем просто запуск тестов: Teamcity используется у нас для сборки демонов и мобильных приложений, и в этих сборках были важны разные функции, вроде шаблонов для конфигураций. Начинали мы с Jenkins, но из чисто субъективных соображений (скорость, которая казалась хуже, чем в Teamcity, внешний вид и сложность/количество настроек) мы перешли на Teamcity. Мы подумываем о том, чтобы посмотреть на альтернативы, возможно, даже выпустим статью с обзором, если наберется достаточно информации.
Было бы интересно услышать о Вашем опыте. :)
Было бы интересно услышать о Вашем опыте. :)
+1
Из статьи сделал один вывод — какое счастье иметь rspec и capybar'у
-4
Неконструктивный комментарий.
Если он означает: "почему вы не использовали rspec и capybar?", то я уже написал об этом. У нас изначально проект на php и unit-тесты используют phpunit. Не имело смысла писать тесты на другом языке и использовать другую пускалку.
К тому же мы покрываем функциональными тестами только ту фичу, которая уже на продакшене. У нас очень гибкая система АБ-тестирования, мой коллега о ней рассказывает тут. Мы редка покрываем фичи, которые не прошли АБ-тестирование. Подход BDD нам не очень подойдет.
Если он означает: "а я программирую на ruby", то я рад. :)
Если он означает: "почему вы не использовали rspec и capybar?", то я уже написал об этом. У нас изначально проект на php и unit-тесты используют phpunit. Не имело смысла писать тесты на другом языке и использовать другую пускалку.
К тому же мы покрываем функциональными тестами только ту фичу, которая уже на продакшене. У нас очень гибкая система АБ-тестирования, мой коллега о ней рассказывает тут. Мы редка покрываем фичи, которые не прошли АБ-тестирование. Подход BDD нам не очень подойдет.
Если он означает: "а я программирую на ruby", то я рад. :)
+3
Sign up to leave a comment.
Покрываем проект smoke-тестами, пока он не сгорел