Pull to refresh

Comments 25

Почему бы не проводить такие проекты (я о школе) удаленно? Собрать группы студентов, организовать вебинары, дать им задания.
Мы заинтересованы в том, чтобы получить максимальный эффект от этой школы. Такое возможно только при очном обучении. Личное общение всегда останется незаменимым инструментом. Тем же кто хочет повысить свои навыки тестирования, но не сможет присутствовать лично, курс можно будет увидеть в онлайне.
Будет опубликовано на хабре?
Да, мы расскажем, когда их выложим. Пока во время школы будем готовить видео.
Зачем манипуляторы поднимают стеклянный колпак (третий робот), а затем опускают его обратно?
Это оптическая иллюзия — робот и колпак пересеклись на одной зрительной линии
Да, вы правы, я не обратил внимания на дальний край колпака.
Тогда зачем манипуляторы снимают стеклянный колпак (третий робот), а затем опускают его обратно? :)
Полируют. Последние два вон какие блестящие :) Готовят к выпуску.
Достойный ответ. И правда, блестящие :)
UFO just landed and posted this here
я возможно промахнулся кнопочкой ответить :) Ответ ниже
1. Предполагается что на функциональность из мержа А и мержа Б есть юнит тесты. Предположим что они приехали одновременно пулл-реквестами. На каждом прошли юнит тесты, они оба успешны. Мержим то что в А. Этот мерж меняет поведение компонента С, на который ссылается мерж Б. Мерж Б требует ребейза на мастер, ибо содержит старые версии тестов на компонент С. После ребейза тесты перезапускаются и падают, сообщая о проблеме. Т.е. о проблеме узнаем перед тем как привели в актуальное к мержу состояние мержа Б.

2. Мерж А не может попасть в основную ветку провалив тесты. Если это произошло случайно, необходимо откатить коммит, поломавший тесты, ибо это прямое нарушение условия «в основную ветку попадают только изменения, прошедшие юнит тесты и ревью». После чего мерж Б попадает в продакшен ничего не зная о мерже А.

3. Тут зависит от схемы выкатки релизов и мягкости условия о стабильности кода в основной ветке. Например, если у нас каждый пулл-реквест — это фактически версия, тут тестировать нужно в ветке мержа безусловно. Тогда в основную ветку попадут уже готовые к выкладке изменения. Т.е. приехало в мастер — выкладываем в продакшен.

Если мы собираем готовую версию только набрав нужное количество изменений, здесь можно тестировать конечный релиз и в основной ветке. Например в нашем Allure Framework в мастере всегда гарантированно просмотренный и прошедший юнит тесты код. Но мы допускаем, что перед выпуском версии можем собрать несколько фич разом в одной сборке и скопом прокликать вручную и тяжелыми тестами все, после чего делать релиз. Это более лояльно ко времени участников — всем не надо проверять регрессию на каждом пулреквесте, мы считаем что в основном ничего не сломали (ибо есть юнит и интеграционные тесты). А какие то глубокие промахи в дизайне или юзабилити можно устранить либо в следующей версии, либо оттянув текущую.

UFO just landed and posted this here
1. Это определяет гитхаб (или геррит, или что используется для организации гитхаб-флоу). У него кнопка пропадает yadi.sk/i/BZ99RBkgbX4fD. Если же ребейз автоматический (т.е. без конфликтов) то гитхаб рассылает пуши об обновлении пулл-реквестов, после которых и происходит пересборка.

2. Цитирую из статьи чуть раньше:
CI-сервер заботливо соберет предложенное изменение, прогонит тесты и обязательно сообщит о проблемах в самом предложении на слияние. <...> После успешной сборки — время для осмотра кода живым человеком

Если билд провалился, над кнопкой рисуется красный крест. Не заметить его сложно. Предполагается что увидев это человек не будет нажимать на кнопку мержа, если он в здравом уме.

Стадия интеграционного тестирования, может мигрировать из основной ветки в ветку с мержем. Интеграционным называется тестирование, проверяющее интеграцию с другими компонентами. Т.е. Возможна ситуация когда интеграционные тесты не проходят, но при этом код в основной ветке полностью рабочий. В этой ситуации нужно смотреть по проекту. Если это какой то важный компонент, то стадию интеграционных тестов нужно делать ДО мержа (вопрос п.3). Если интеграция с другими компонентами — проблемы других компонентов, то тут можно сэкономить, не запуская тестов на интеграцию на каждый мерж, а только перед непосредственно релизом, чтобы уведомить других что у них что-то может сломаться.

3. Мастер не ломается. Поломка на интеграционном тестировании не считается поломкой мастера. Ибо код в мастере рабочий и успешно проходит юнит тесты. Тут вопрос процесса — если считать интеграцию достаточно важной составляющей рабочего продукта и рабочего мастера — тогда конечно.

UFO just landed and posted this here
UFO just landed and posted this here
Как любит повторять создатель дженкинса «Polling must die!»
У гитхаба очень хороший механизм хуков. Это специальные нотификации, которые представляют из себя POST запрос по заранее заданному урлу. Гитхабу просто скармливается список урлов, которые он должен дернуть в случае наступления определенных событий. Дальше CI сервер принимая пуш на свой урл смотрит к какой сборке этот пуш относится.
Картинки:
yadi.sk/i/gT5p6weDbX8T8
Если зайти в конкретный хук, можно увидеть когда были отправлены пуши
yadi.sk/i/f0gHaGSpbX8Z5

2. Тесты делятся обычно на юнит-тесты (те которые непосредственно код тестируют). Интеграционные (они тестируют компонент целиком в вакууме, заглушив все внешние компоненты заглушками и проверяя, что наш компонент взаимодействует с остальными корректно — вызывает нужные методы, рассылает нужные уведомления). Функциональные тесты (они проверяют бизнес логику). End-to-end тесты (те которые смотрят как ведет себя вся цепочка взаимосвязанных компонентов). Тесты на отображение UI (обычно это скриншотные тесты, тесты на то что все элементы действительно видны итд). Замыкают пирамиду на самом верху тесты ручные, часть из которых замещается автоматическими тестами, имитирующими конечного пользователя — WebDriver тесты.

Собственно никаких противоречий где все тесты запускать нет — это вопрос удобства и требований к качеству на каждом из этапов. Просто чем выше пирамида, тем более долгие и тяжелые тесты. Поэтому, например, вебдрайверные тесты почти нереально запускать на каждый коммит, если тестировать ими серьезные сценарии.
Интеграционные тесты исходя из этого могут быть частью сборки, а могут быть частью релиза. Если делать их частью сборки, то они проходят во время каждого билда и если они здесь сломаются, эффект от их поломки будет аналогичным поломке юнит-тестов. Если делать их частью релиза, то тогда они запускаются только на стадии, когда мы хотим сделать релиз. Тогда все что хотелось мержить в рамках этого релиза можно мержить при условии успеха юнит-тестов и успеха ревью. Далее релиз фиксится до победного БЕЗ добавления новых фич. Новые фичи ждут в своих мерж ветках момента, когда будет выпущен релиз и на зарелиженный мастер можно будет заребейзиться.

На примере:
У нас есть модуль авторизации. Мы покрыли юнит тестами что при заполнении логина, пароля у нас заполняется модель пользователь, мы покрыли юнит тестами что у нас нет исключений при невалидных значениях данных, и что мы по готовности отправляем сериализованную модель в нужном формате куда скажут.

Интеграционные тесты. Здесь мы ставим заглушку на бд, и проверяем что до бд действительно доходит то же самое, что мы сериализовали в модуле авторизации. Так же, мы проверяем, что если мы запросили авторизацию с верными данными, нам вернулся код ответа 200 ОК. И если неверные, то 403 FORBIDDEN. То что мы умеем отсылать коды ответа мы проверяем в юнит тестах. Аналогично ставим заглушку на модуль который пишет журнал, и смотрим, что если мы запросили доступ, то до журнала долетела запись.

Функциональные тесты. Мы поднимаем бд, заполняем ее пользователями для проверки. Авторизуемся пользователем из бд и не из бд, и смотрим что нам пришли нужные коды ответа, а в журнале действительно сохранилась запись.

ну и дальше — больше участников просто и больше слоев.

UFO just landed and posted this here
Последовательность верная. По крайней мере в гитхабе и геррите так работает.

В гитхабе во время сборки есть индикатор над кнопкой, показывающий что идет сборка.

Если прям секунда в секунду взять и смержить все что было, не успев среагировать на изменения интерфейса — тут честно признаюсь, не знаю что будет. Ну кажется выходом будет только проглядывать ленту изменений перед слиянием. Мне сложно представить процесс разработки большого продукта в котором часто что-то мержат, при этом делают это абсолютно молча и игнорируя чужие пул-реквесты. Тут кажется проблема уже не на стороне системы сборки а на стороне менеджмента и коммуникации между разработчиками. Поэтому решать нужно именно ее, а не думать как разруливать бесконтрольные ломающие друг друга мержи.
1.
Например, для Jenkins + GitHub это GitHub PRBP.
Для Jenkins + Bitbucket это Bitbucket PRBP.
Для Teamcity + Github это TeamCity.GitHub.

А для Teamcity + Bitbucket существует?

2.
В чем особенности работы с Bitbucket по сравнению с GitHub'ом?

3.
Тесты делятся обычно на юнит-тесты...

Давно искал такого описания типов тестов, спасибо. Где можно подробнее почитать?
1. Путем несложного поиска нашел: github.com/ArcBees/teamcity-plugins/wiki/Configuring-Bitbucket-Pull-Requests-Plugin
2. Битбакет поддерживает не только git + у него есть приватные репозитории. Наверное это может наложить какие то особенности. + Разное api. Это может повлиять на функциональность конечной связки. Но в целом, особых отличий быть не должно. Речь идет только о каких-то дополнительных плюшечках.
3. Для того чтобы хорошо ориентироваться в автоматизации, тестировании и разработке обязательно стоит почитать эту литературу:
1) «Sun Certified Programmer for Java Platform, SE6» Richard F. Raposa
Пособие по подготовке к соответствующему сертификационному экзамену. Рассматриваются все основы языка. Скорее всего, есть только в английском варианте.
2) «Effective Java» Bloch Joshua
Продвинутый уровень, помогает глубоко понять идеологию java. Есть русский перевод, «Java. Эффективное программирование»
3) «Refactoring: Improving the Design of Existing Code» Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
Продвинутый уровень, не только по java. Есть русский перевод, «Рефакторинг. Улучшение существующего кода»
4) Сэм Канер, Джек Фолк, Енг Кек Нгуен. Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений
5) Роман Савин, teстирование dот com
6) Гленфорд Дж. Майерс «Искусство тестирования программного обеспечения»
7) Шаблоны проектирования xUnit

Sign up to leave a comment.