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