headless chrome вышел?))

почему перестал?

уехал на докеризованный хром - намного удобнее

вышел, но я с ним сегодня весь день воюю, фигня какая-то

уехал на докеризованный хром - намного удобнее

selenoid?

selenoid?

нет, зачем он) просто ремоут браузер в контейнере

хм, а если всё остальное не в докере имеет смысл замарачиваться? получается нужно будет на одну виртуалку больше

нет, зачем он) просто ремоут браузер в контейнере

а у тебя своя сборка хрома или чото из хаба подобрал?

хм, а если всё остальное не в докере имеет смысл замарачиваться? получается нужно будет на одну виртуалку больше

что остальное?

само приложение, у нас всё рядышком лежит

а у тебя своя сборка хрома или чото из хаба подобрал?

я беру сборку хрома из официальной репы докер-селениума

самодельную не вижу смысла делать :)

само приложение, у нас всё рядышком лежит

приложение-то никак не относится к тому, где живет браузер, но оно тоже докеризовано

и тесты в докер-контейнере бегают

правильно я понимаю,что есть докеры с браузерами, докер с окружением для прогона тестов, который например через гит стягивает свежие тесты?

правильно я понимаю,что есть докеры с браузерами, докер с окружением для прогона тестов, который например через гит стягивает свежие тесты?

ага. он монтирует исходники тестов в контейнер и ранит их

а дженкинс тоже в докере?

а дженкинс тоже в докере?

нет, зачем :)

у меня тимсити так-то, но смысла пихать все в контейнеры нет

а дженкинс тоже в докере?

Советую почитать что такое докер и где его стоит применять

О мы почти год назад ушли в докер, я очень проникся им, очень удобно

Докер+кубернетис

ага, контейнеры это космически удобно. но не для всего

Ну зависит от проекта

У нас все инфраструктура в контейнерах. Масштабировпться слишком удобно, будь то прод, тесты, или тестовые серваки

и база в контейнере? :)

Да

С этим отхватили проблем

Но уже все решено )

и база в контейнере? :)

Лично на моем проекте подняли cassandra в докере, и ничо

мы увезли базу из контейнеров – сильно удобнее ее рулить в чистом виде

Овна конечно я хлебнул с коммитлогами, но справился

У нас saas решение, по другому поставлять не удобно

а язык?

Java ,cpp Бекенд

Каждый сервис в своём контейнере

Привет! А кто-нибудь занимался автоматизацией тестирования через сравнение скриншотов? Интересен любой опыт, стоит ли оно усилий.

Привет! А кто-нибудь занимался автоматизацией тестирования через сравнение скриншотов? Интересен любой опыт, стоит ли оно усилий.

Помнится, у нас такое на митапе обсуждали.

смотря что ты хочешь тестировать

если не верстку – то скорее нет, чем да

android приложение

если не верстку – то скорее нет, чем да

а можешь мысль развернуть? был негативный опыт с мобильными? или что, если не верстку?

Помнится, у нас такое на митапе обсуждали.

а видео есть? к чему пришло обсуждение?

с мобильниками у меня нет никакого опыта. кто-то пытается тестировать бизнес-логику скриншотами и это так себе занятие :)

а видео есть? к чему пришло обсуждение?

Видоса нет, но ребзя имеют эталонные скрины. Если картинка отличается - тест фейлится, область, где картинка не совпала - подсвечивается

Видоса нет, но ребзя имеют эталонные скрины. Если картинка отличается - тест фейлится, область, где картинка не совпала - подсвечивается

и как это у них работает? какой процент постоянно фейлится? получилось им увеличить покрытие по девайсам/ОС, ручным тестировщикам легче стало?

мне интересно, стоит ли вообще в это направление инвестировать время, будет ли там полезный выхлоп

и как это у них работает? какой процент постоянно фейлится? получилось им увеличить покрытие по девайсам/ОС, ручным тестировщикам легче стало?

Они тестят таким образом рисунок на канвасе и все.

а что за ребята?

из какой конторы?

Ответил в лс

да, спасибо

с мобильниками у меня нет никакого опыта. кто-то пытается тестировать бизнес-логику скриншотами и это так себе занятие :)

почему? в теории таким образом можно мануальные регрессии заменить.

почему? в теории таким образом можно мануальные регрессии заменить.

потому что скриншоты очень чувствительны к минимальным изменениям чего угодно – информации на странице, лэйауту интерфейса. если приложение совсем статичное, то возможно, для сколько угодно сложных приложений – тяжеловато

потому что скриншоты очень чувствительны к минимальным изменениям чего угодно – информации на странице, лэйауту интерфейса. если приложение совсем статичное, то возможно, для сколько угодно сложных приложений – тяжеловато

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

я на старой работе внедрял. там был аутсорс проект где не оплачивали регресс, но было дофига ломающейся вёрстки. делали свою штуку на рельсах, за основу брали фантом цсс. Рекламные баннеры рубили на хостах, страницы выбирали статичные - работало вроде нормально

я на старой работе внедрял. там был аутсорс проект где не оплачивали регресс, но было дофига ломающейся вёрстки. делали свою штуку на рельсах, за основу брали фантом цсс. Рекламные баннеры рубили на хостах, страницы выбирали статичные - работало вроде нормально

просто обозначали несовпадающие области или как-то детектили, в какой части и что именно сломалось?

оно умело части определять, но мы по целой странице смотрели, требование было простое, чтобы старое ничего не отвалилось

А чем отличается stub от mock ?

чувак, лучше забудь, что тебе наобъясняли, и всё же вчитайся в статью Фаулера, которой с тобой поделились. Или посмотри пересказ тут http://merle-amber.blogspot.ru/2008/09/mock.html

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

а то последовавшее обсуждение - какой-то треш

как ты их делаешь, если не понимаешь пользы и разницы? и зачем?

Это как с паттернами - используешь 5 лет свой хитрый придуманный трюк во всех проектах, приходишь на собеседование и узнаешь что это оказывается называется делегат.

как ты их делаешь, если не понимаешь пользы и разницы? и зачем?

сам в шоке

не путай проектирование кода и виды проверок в тестах

как ты их делаешь, если не понимаешь пользы и разницы? и зачем?

прекрасно делается

ERROR: S client not available

factory girl или vhs

или любая другая mock либа

Фаулер, конечно, молодец, крутой чувак, но зачастую 70% дефинишн-булшита можно выбрасывать

это касается его, Еванса с его DDD, Баха и целой кучи других, которым нужно написать столько, чтобы хватило на книжку

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

примеры плиз

одно дело проверять состояние, другое дело - поведение тестируемой сущности

тут было много сказано о теории и о том, как это интепретировать

Если мне нужно что-то проверить, я просто придумаю способ это проверять, и плевать как это там назовется, стаб или мок :)

и ни 1ого живого примера продакшн кода как всю эту разношерстную номенклатуру видеть и понять,, что оказывается в Python \ JS \ Ruby \ Php мире это нужно и различается

Ну кстати яркий пример - это то что у Фаулера называется Spy - объект который в себе счетчики содержит. Можно 10 лет городить такие объекты со счетчиками и анализаторами, подсовывать их в тестах и прекрасно жить, и умереть даже не зная что это оказывается называется *Spy* ?

Если мне нужно что-то проверить, я просто придумаю способ это проверять, и плевать как это там назовется, стаб или мок :)

приходилось писать юнит-тесты и проверять ими, что при выполнении тестируемый метод провел определенные действия и в правильной последовательности?

Ну... наверно. Я уже не помню.

если нет, то значит моки как раз и не использовал. возможно, от того и непонимание разницы

Очевидно что когда встанет такая задача, я построю прокси-объекты для этих действий, которые помимо основной функциональности будут выбивать флаги того что они выполнились, а потом в конце проверять что получилась упорядоченная последовательность.

У моего фреймворка есть всякие методы ->call(atLeastOnce()) и т.д. Это как-то называется? =)

а моки, в общем, и нужны, чтобы проверить не выходное значение того же метода, а то, каким образом он этого добился, что он делал внутри себя

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

Или что он ни разу не дергался, или что кинул опред. исключение.

интересная позиция :) когда под видом моков тебе показывают стабы, то охотно киваешь, что понял, потом то же и другим расскажешь. А при предложении посмотреть почти что на первоисточник классификации - не надо мне это всё, я и раньше как-то неплохо жил без этих знаний :)

Ну я не сказал что не буду это читать

Просто чуть попозже. А пока я понял что и без этого можно нормально жить.

абсолютли

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

и что вызван именно из твоего тестируемого объекта

если терминология плодит непонимание - она не нужна

Просто например, если я хочу чтобы метод какого-то объекта возвращал число 42, я могу создать объект и подменить у него метод, сказав что он всегда возвращает 42, а могу просто создать тестовый класс-наследник и перекрыть этот метод, вписав туда return 42. В первом случае это будет мок, во втором стаб. Но результата мы добились одного и того же.

если терминология плодит непонимание - она не нужна

?

в обоих случаях это обычный стаб

лучше напишите на вашем языке задачку, будет полезнее: a.x = 1 a.x = 2 a.x >> [1,2]

ты эмулируешь вывод чего-то и тебе без разницы, когда он вызывался и откуда

А если в классе наследнике в первый раз возвращать 42 а во второй кидать исключение то он станет моком? ?

лучше напишите на вашем языке задачку, будет полезнее: a.x = 1 a.x = 2 a.x >> [1,2]

статью принципиально не смотрел?