Комментарии 46
Про тесты верстки было бы очень интересно почитать. И спасибо за статью.
проверка — неотъемлемая часть) Спасибо.
чем это лучше тестов контроллеров?
Тесты нужно поддерживать — писать новые и менять старые — а эта схема работает без затрат времени на тесты. В том и плюс!
Так по сути это тесты структуры базы? Ибо тесты контроллеров и должны выявлять минимум 500-ые ошибки. И покрывают они намного больше функционала. Да и разрабатывать просто — сделал руками запрос, и повторяй сколько хочешь пока тест не пройдет.
Это по сути — не тесты! У меня нет желания искать развалившийся код такоим сложным путем. Тесты — юнит, функциональные, интеграционные — проверяют бизнес-логику.
В нашем CI нет задачи проверки бизнес логики — как мы её проверяем — отдельная тема.
Задача этой схемы билда — проверка целостности, проверка того, что ничего не сломалось, то что раньше работало. Вот пример:
Если Вы будете искать ошибки вида «juniur не имплементировал абстракный метод в одном из потомков» функциональными тестами, то цена нахождения такой ошибки слишком велика — N минут разработчика на тест, для поиска ошибки сделанной за 0 минут. В нашем случае 0 минут разработки тестов, на тупую ошибку.
В нашем CI нет задачи проверки бизнес логики — как мы её проверяем — отдельная тема.
Задача этой схемы билда — проверка целостности, проверка того, что ничего не сломалось, то что раньше работало. Вот пример:
Если Вы будете искать ошибки вида «juniur не имплементировал абстракный метод в одном из потомков» функциональными тестами, то цена нахождения такой ошибки слишком велика — N минут разработчика на тест, для поиска ошибки сделанной за 0 минут. В нашем случае 0 минут разработки тестов, на тупую ошибку.
Я думаю то, что вы называете проверка работоспособности относится к smoke tests'ам
То, что вы делаете — это как раз интеграционные тесты. Когда-нибудь придёте к полноценным юнит-тестам, когда надоест разбираться «почему не работает» и «где не работает».
Хотя, конечно, интеграционные тесты — это лучше, чем ничего.
Хотя, конечно, интеграционные тесты — это лучше, чем ничего.
Тесты не нужно поддерживать, если не меняется интерфейс. Если интерфейс всё-таки меняется, то придётся менять и скрипт «это у нас проверка, а не тестирование».
Вот она, золотая середина между полным отсутствием автоматической проверки и полным покрытием всего проекта тестами :) Как всегда, все гениальное — просто. Спасибо за идею!
Ничего нового не узнал. То что Вы делаете очередная никому-не нужная белиберда, не важно для Yii она сделана или еще для чего-то.
Обычно работает немного не так все — делается хук на коммит в систему-контроля-версий(Code Sniffer+Black Mesa); этим обеспечен выровненный код-стайл и отсутствие сложных конструкций в любой не-локальной ветке разработчика.
Далее все заливается в какую-то ветку, и на ней проводится регрессивное тестирование. Затем эта ветка попадает в продакшн.
Какой-то псевдонаучный бред про то почему Вы и как используете Selenium я постарался пропускать, к делу это не относится.
Дальше Вы пишите — у нас мало «Unit-Тестов» с чем Вас и поздравляю. О чем статья в итоге так и не понял… Разьве что дифф скриншотов по верстке идея достаточно оригинальная(для меня по крайней мере).
Обычно работает немного не так все — делается хук на коммит в систему-контроля-версий(Code Sniffer+Black Mesa); этим обеспечен выровненный код-стайл и отсутствие сложных конструкций в любой не-локальной ветке разработчика.
Далее все заливается в какую-то ветку, и на ней проводится регрессивное тестирование. Затем эта ветка попадает в продакшн.
Какой-то псевдонаучный бред про то почему Вы и как используете Selenium я постарался пропускать, к делу это не относится.
Дальше Вы пишите — у нас мало «Unit-Тестов» с чем Вас и поздравляю. О чем статья в итоге так и не понял… Разьве что дифф скриншотов по верстке идея достаточно оригинальная(для меня по крайней мере).
Не узнали, а жаль. Есть понятие производственной стабильности, оно мало применятся к IT, а вот тут реально жаль. В описанным Вами методе он нарушается: «заливание в ветку» — это плюс к нестабильности (т.к. мерж может быть кривым).
Регрессивное тестирование — а у Вас есть 5 человек QA, которым Реально Приятно заниматься регрессивным тестированием? Уверен, что 90% QA такое не любят. А заставлять людей делать то что им неприятно — они делают это менее внимательно — вот еще минус к стабильности.
Про систему контроля версий и хук — а Вы серьезно думаете что я руками запускаю билды? Естественно нет. И точно не по хуку — более умным способом, чтобы не билдить каждый git push. Смысл есть билдить результат закрытого тикета, а не все что пушат. Билд нашего приложения длится 30 минут. Вот представьте, если пушат раз в минуту — за день наберется очередь билдов, которая будет разгребаться еще неделю!
Регрессивное тестирование — а у Вас есть 5 человек QA, которым Реально Приятно заниматься регрессивным тестированием? Уверен, что 90% QA такое не любят. А заставлять людей делать то что им неприятно — они делают это менее внимательно — вот еще минус к стабильности.
Про систему контроля версий и хук — а Вы серьезно думаете что я руками запускаю билды? Естественно нет. И точно не по хуку — более умным способом, чтобы не билдить каждый git push. Смысл есть билдить результат закрытого тикета, а не все что пушат. Билд нашего приложения длится 30 минут. Вот представьте, если пушат раз в минуту — за день наберется очередь билдов, которая будет разгребаться еще неделю!
Как уже писали ниже, пул-реквесты исключают кривые мержи.
Зачем каждый коммит? Все что в dev/master ветку пушится.
UPD 30 минут билд — что в него входит?
Зачем каждый коммит? Все что в dev/master ветку пушится.
UPD 30 минут билд — что в него входит?
лишняя проверка никогда не лишняя.
30 минут:
* 2 схемы деплоя: итеративная миграция и с нуля (с установкой debian, конфигурированием и разверкой кода) — на это нужно 5 минут.
* selenium у нас обходит 100% интерфейса — на это нужно 15 минут.
* 1-5 минут нужно на имеющиеся unit и функциональные selenium тесты старых багов. Да, к сожалению selenium штука не быстрая
* 1-5 минут нужно на тесты библиотек.
Вот и 22-30 минут на билд. Билдим мы 3 бранча — master (stable), alpha (alpha-версия), beta (beta-версия).
30 минут:
* 2 схемы деплоя: итеративная миграция и с нуля (с установкой debian, конфигурированием и разверкой кода) — на это нужно 5 минут.
* selenium у нас обходит 100% интерфейса — на это нужно 15 минут.
* 1-5 минут нужно на имеющиеся unit и функциональные selenium тесты старых багов. Да, к сожалению selenium штука не быстрая
* 1-5 минут нужно на тесты библиотек.
Вот и 22-30 минут на билд. Билдим мы 3 бранча — master (stable), alpha (alpha-версия), beta (beta-версия).
30 минут — это очень много на самом деле.
ИМХО. Для каждого пуша в фича ветки — запускать smoke тесты. Библиотеки вынести отдельно.
После мержа в beta запускать «итеративную миграцию»(я так понимаю это обычный апдейт в репосе), чтобы на интеграционном хосте уже был результат и QA могли работать. Деплой с нуля, UI тестинг и функциональщина — это 3 отдельных задачи для дженкинса и они могут выполняться параллельно. Советую использовать плагин для Jenkins — Build Pipeline, в вашем случае очень пригодится
ИМХО. Для каждого пуша в фича ветки — запускать smoke тесты. Библиотеки вынести отдельно.
После мержа в beta запускать «итеративную миграцию»(я так понимаю это обычный апдейт в репосе), чтобы на интеграционном хосте уже был результат и QA могли работать. Деплой с нуля, UI тестинг и функциональщина — это 3 отдельных задачи для дженкинса и они могут выполняться параллельно. Советую использовать плагин для Jenkins — Build Pipeline, в вашем случае очень пригодится
зачем если не секрет вы поднимаете новую виртуалку? А что вы будете делать когда этот процесс станет невозможен вследствии сложности проекта и завязки его на системные решения?
Этим мы по сути проверяем схему развертывания новой ноды в нашем кластере. По сути это тестирование автоматизации горизонтального масштабирования — у нас оно выполняется нажатие кнопки в панели полностью автоматически. Проверить правила автоматического развертывания сервисов для puppet, проверить, что конфиги в хранилище актуальны, и многое другое — это спасение от неожиданностей на проде. Неожиданностей вида — «а вот на эту новую ноду надо доустановить такой-то модуль php».
Проект и сейчас сильно завязан на системные решения, системное администрирование у нас сложное и по этому полностью автоматизировано — его тоже следует проверять. Развертка с нуля у нас — это установка 5и виртуалок и их настройка — минимальный размер кластера для нашего продукта.
Невозможен? А как может оказаться так, что продукт нельзя установить на новую машину?
Проект и сейчас сильно завязан на системные решения, системное администрирование у нас сложное и по этому полностью автоматизировано — его тоже следует проверять. Развертка с нуля у нас — это установка 5и виртуалок и их настройка — минимальный размер кластера для нашего продукта.
Невозможен? А как может оказаться так, что продукт нельзя установить на новую машину?
это значит что затраты на поднятие виртуалки будут гораздо большие чем профит от развертывания вашего гипотетического кластера на 5 серверов. У вас 100500 серверов что надо при каждом билде тестить новый кластер? Оч. сомневаюсь…
У меня достаточно ресурсов чтобы для каждого билда поднять 5 виртуалок, собрать билд а потом их удалить.
Получается, что после изменений в php коде вы проверяете скрипты puppet, какой смысл? Не лучше ли будет проверять сборку «кластера» после ченжей в puppet скриптах? Другой вопрос, не лежат ли puppet скрипты вместе с общим кодом…
Вы извратили мои слова как только могли. Пуш в удаленную ветку разработчика с хуком — не имеет ни малейшего отношения ни к описанной мной RC ни к master ни к билдам.
Достаточно было простых smoke тестов курлом после билда, если, как вы говорите, фаталы — 50х ошибки вылезут сразу же.
Для проверки Javascript и CSS валидности советую использовать Gruntjs с jshint и csslint.
Для проверки Javascript и CSS валидности советую использовать Gruntjs с jshint и csslint.
Не уверен, что достаточно. Когда то мы тоже так делали, но вот итоговая эффективность проверки была гораздо ниже (примерно на 70%), т.к. нет явной проверки работы моделей — которую я описал. И курлом не всегда все можно «продергать» — особенно в случае полностью ajax-приложения, где url вызываемые нажатием на кнопку берется не просто из href, а конструируется более сложным способом.
Ну вот все сложные и «проблемные» схемы можно дергать курлом.
С моделями у нас когда-то тоже были такие проверки, но они подойдут только для несложных CRUD операций. Когда таких бесполезных тестов накопилось большое количество — от них отказались и начали мокать все обращения к бд, иначе скорость хромает. А что если будут сложные выборки на 2-3 таблицы, как их проверяете?
С моделями у нас когда-то тоже были такие проверки, но они подойдут только для несложных CRUD операций. Когда таких бесполезных тестов накопилось большое количество — от них отказались и начали мокать все обращения к бд, иначе скорость хромает. А что если будут сложные выборки на 2-3 таблицы, как их проверяете?
Таких тестов никогда не будет много — на все модели он один и бегает циклом по моделям. Один потому что все модели стандартны и похожи.
Выборки из 2-3 таблиц у нас не бывают, это запрещено. У нас высоконагруженый проект: Join-ы, Union-ы, subquery и прочее — убивает почти любой сервер БД на нагрузках 2000 хитов в секунду — это не раз проверено, так работаем не только мы, но и, например, Facebook. Так же выборки их N таблиц сходу ломают идею шардинга. Сложные запросы хороши в решениях уровня предприятия или малого проекта, но не в нашем случае.
Идея вобщем то не в том, как я сделал реализацию, а в том, что все части системы имеют стандартный вид и их очень просто проверять (не тестировать!) — один тест покрывает 5 сущьностей подходящих под один стандарт, например модели.
Это как ГОСТ на гайки. Если любая гайка имеет 6 граней — это легко проверить одним автоматом, а вот если бы гайки имели разное количество граней — то на каждый тип граней пришлось бы делать разные проверяющие автоматы.
Идея имено в стандартах на сущьности и в том что это легко проверять, а не в том как мы применили эту идею к нашему проекту.
Выборки из 2-3 таблиц у нас не бывают, это запрещено. У нас высоконагруженый проект: Join-ы, Union-ы, subquery и прочее — убивает почти любой сервер БД на нагрузках 2000 хитов в секунду — это не раз проверено, так работаем не только мы, но и, например, Facebook. Так же выборки их N таблиц сходу ломают идею шардинга. Сложные запросы хороши в решениях уровня предприятия или малого проекта, но не в нашем случае.
Идея вобщем то не в том, как я сделал реализацию, а в том, что все части системы имеют стандартный вид и их очень просто проверять (не тестировать!) — один тест покрывает 5 сущьностей подходящих под один стандарт, например модели.
Это как ГОСТ на гайки. Если любая гайка имеет 6 граней — это легко проверить одним автоматом, а вот если бы гайки имели разное количество граней — то на каждый тип граней пришлось бы делать разные проверяющие автоматы.
Идея имено в стандартах на сущьности и в том что это легко проверять, а не в том как мы применили эту идею к нашему проекту.
Join-ы, Union-ы, subquery и прочее — убивает почти любой сервер БД на нагрузках 2000 хитов в секунду
Я думаю, что Вы врете. Можно пруф хоть какой-нибудь?
так работаем не только мы, но и, например, Facebook
Я могу предположить, что они по архитектурным причинам не могут их использовать.
Так же выборки их N таблиц сходу ломают идею шардинга.
Смотря как шардить.
У Вас данные денормализованы и Вам достаточно одного запроса? Или Вы делаете 2 селекта подряд и думаете, что это круто?
Ребята, а вам не кажется, что вы идете кривой дорожкой? Вместо того чтобы регулярками вылавливать факапы мерджей(лол, я реально удивился), стоило бы ввести код-ревью через пул-реквесты. Серьезно, попробуйте. И так далее, вплоть до виртуалки на отдельный бранч. И шаг (3) у вас, это что вообще такое? Ну, возможно я невнимательно прочитал. Но если бы практиковалось BDD — таких проблем бы в принципе не возникало.
«регулярками вылавливать факапы мерджей» — ревью естественно есть, и пул-реквесты тоже — мы используем gitlab. Просто людям свойственно ошибаться и забывать любой разработчик даже опытный, в определенных условиях менее внимателен и может допустить такую ошибку.
Моя задача не отказаться от тестирования, и не отказаться от код-ревью — задача передать тестировщикам рабочий код, чтобы они не занимались поиском фаталов, а проверяли бизнес логику. Конечная цель — стабильное приложение. Минимум косяков на проде, и не ценой замучанных регрессивными проверками QA :-)
Моя задача не отказаться от тестирования, и не отказаться от код-ревью — задача передать тестировщикам рабочий код, чтобы они не занимались поиском фаталов, а проверяли бизнес логику. Конечная цель — стабильное приложение. Минимум косяков на проде, и не ценой замучанных регрессивными проверками QA :-)
Ну при код-ревью это само-собой видно, нет? Меня такая автоматизация и удивила :) А вообще, мы поступаем следующим образом. Решили сделать отдельный сервис, суть в чем. Через github api дергается список бранчей, и для каждого из бранчей тестер одним нажатием кнопки может поднять витруалку. Она поднимается, деплоится, порты www, ssh и vnc пробрасываются. Ему остается только протестировать, сказать что все ок, и удалить виртуалку. Тогда уже код вливается в master.
Недавно как раз интервью было с бадушниками, там все это обсуждалось
5xx — не нужно фаталить при кривых запросах, нужно давать пользователю осмысленную ошибку “что он делает не так”.
Спорный подход. Если хакер занимается подбором параметров чего бы поломать в системе, ему тоже писать осмысленную ошибку «что он делает не так»? Я специально ставлю по коду asserts, главное предназначение которых не дать разработчику криво вызвать функцию. Естественно для конечного пользователя идут обработки исключительных ситуаций и показываются ему ошибки, но только до тех пор, пока пользователь соблюдает протокол общение и не лезет в переменные GET/POST. Если программа вызывается способом, не предусмотренным разработчиками, ошибка обязательно должна быть, она должна прийти нам в Sentry, подлежит дальшейшему анализу и мы уже решаем что делать дальше — насколько вменяема и возможна данная ситуация, была ли попытка взлома и что делать дальше. Главное тут в том, что ошибки 500 показывают нам действительно внутренние ошибки…
Знать об ошибке, залогировать её и доложить в мониторинг — это одно. об ошибке bad request стоит докладывать — но это не повод нарушать http и на кривой запрос отвечать не 400, а 500 — как будто это внутреняя ошибка сервера. Тем более это не повод, чтобы код падал.
Мне ничего не мешает мониторить http status 400
Мне ничего не мешает мониторить http status 400
Статья хороша, спасибо!
Начал писать комментарий, но в итоге родился целый пост — habrahabr.ru/post/191242/
Начал писать комментарий, но в итоге родился целый пост — habrahabr.ru/post/191242/
Идея понравилась, как раз совесть мучала из за не пишу никогда тесты. Для второго шага мы использовали pear.php.net/package/PHP_CodeSniffer/. Скорее всего возьму вашу идею на вооружение. Автору спасибо.
Вы примерно описали Smoke-тестирование
ru.wikipedia.org/wiki/Smoke_test
ru.wikipedia.org/wiki/Smoke_test
Видимо в CRUD тесте вы пропустили редактирование данных и смену значения scenario.
А в методе ModelClass::createDefault() вы формируете заведомо правильные данные на основе правил валидации, однако как вы проверяете достаточность правил валидации?
И как поступаете с нестандартными правилами валидации?
А в методе ModelClass::createDefault() вы формируете заведомо правильные данные на основе правил валидации, однако как вы проверяете достаточность правил валидации?
И как поступаете с нестандартными правилами валидации?
Это всё, конечно, прекрасно (одних технологий и методик можно штук десять вписать в резюме). Но такими полумерами выстроена дорога в ад для тех, кто придёт к вам или вместо вас. Да и для вас самих, вы это поймёте в тот момент, когда ваше детище уже не сможет поддерживать ваш разросшийся код, но отказаться от этого детища будет жалко. Этот период мучений обычно занимает от полугода.
Если коротко — кастомный полурабочий сложноизучаемый мусор, возникший от плохой лени.
Если коротко — кастомный полурабочий сложноизучаемый мусор, возникший от плохой лени.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yii, непрерывная интеграция — как не сломать все