Ну, т.е. да, эти данные можно собирать и использовать. Но я не думаю, что их стоит использовать. Т.е. что это целесообразно.

если это ничего не стоит и может помоч, то целесообразно, как мне кажется

Всем привет! Есть ли кто то с опытом по espresso? Есть небольшой вопрос по intents

если это ничего не стоит и может помоч, то целесообразно, как мне кажется

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

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

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

Звучит как автотесты. Написал один раз и гоняешь.

Правда все мы тут знаем, что это немного не так.

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

Ну, т.е. сделать метрики ради красивого дашбордика с автотестами - это хорошо и здорово. Можно ещё прогресс тест-ранов отображать в виде flappy bird или ещё чего-нибудь. Но серьезно, я вот не очень представляю, о чем должен сигнализировать рост времени выполнения теста на 3.5% по сравнению с N последних прогонов. Это не говорит о наличии проблемы в продукте, это даже не говорит о проблеме в тестах. Собирать метрики, отклонения которых могут указывать на наличие проблемы, а могут и не указывать - так себе удовольствие. Потому что на 10ое false-positive срабатывание на них просто все забьют.

если честно, не приходилось собирать никакую стату по тестам. в текущем проекте все тесты - это автотесты. их работа и результаты прогонов - все в CI. Если тест падает, ты не чешешь репу смотря на статистику, ты смотришь на результат прогона. я не исключаю, что у кого-то чем дальше процесс принятия решений дебага тестов от непосредственно фидбека теста, тем больше смысла от статистики. Но пока у тебя получается be as small as you can - любая статистика, бдд головного мозга и прочая чепуха, которая охотно продается и покупается - будет вредна.

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

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

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

Ещё раз повторю: смысл стастистики не в том, что бы её собирать. От того, что она собралась никому ни жарко ни холодно. С ней надо работать, это требует времени. Лучше потратить это время на анализ статистики приложения, чем на анализ тестовых прогонов, ей богу.

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

Кажется для первого есть performance тесты, а второе будет видно в CI, нет?

Ещё раз повторю: смысл стастистики не в том, что бы её собирать. От того, что она собралась никому ни жарко ни холодно. С ней надо работать, это требует времени. Лучше потратить это время на анализ статистики приложения, чем на анализ тестовых прогонов, ей богу.

Ок, может вы собираете какую-то сложную статистику и работать с ней трудно

Ок, может вы собираете какую-то сложную статистику и работать с ней трудно

Я уже выше привел пример: Я вот не очень представляю, о чем должен сигнализировать рост времени выполнения теста на 3.5% по сравнению с N последних прогонов. Это не говорит о наличии проблемы в продукте, это даже не говорит о проблеме в тестах. И в принципе то же самое относится ко всем метрикам, которые я перечислил в сообщении, с которого эта дискуссия началась.

Я уже выше привел пример: Я вот не очень представляю, о чем должен сигнализировать рост времени выполнения теста на 3.5% по сравнению с N последних прогонов. Это не говорит о наличии проблемы в продукте, это даже не говорит о проблеме в тестах. И в принципе то же самое относится ко всем метрикам, которые я перечислил в сообщении, с которого эта дискуссия началась.

О том что тесты теперь медленее бегают - тебя это либо устраивает, либо нет

Это говорит о том, что какие-то из тестов стали по каким-то причинам бегать медленее. Что мне это дало? Что они стали бегать медленнее я узнаю из CI и так, там есть build history. Там есть build time по фазам. Всё ж хорошо и классно. Если меня перестанет это устраивать - я не стану искать тот тест, который стал бегать на 3.5% медленее и чинить его, а поставлю себе задачу "Ускорить тесты на N" и буду решать эту проблему.

И в итоге какой смысл метрики-то?

Для профайлинга приложения есть перформанс тесты, там другая логика: не уложился в N -> test failed, soryan bratan. Есть мониторинг производительности приложения, который говорит про то, как быстро приложение работает, а не про то, как быстро тесты бегут. Это - полезная метрика, да.

Для профайлинга приложения есть перформанс тесты, там другая логика: не уложился в N -> test failed, soryan bratan. Есть мониторинг производительности приложения, который говорит про то, как быстро приложение работает, а не про то, как быстро тесты бегут. Это - полезная метрика, да.

если у тебя 100 тестов, то да, а если 1000 или 10000? и с каких пор время прогона тестов на CI не является метрикой:)

если у тебя 100 тестов, то да, а если 1000 или 10000? и с каких пор время прогона тестов на CI не является метрикой:)

С тех пор, как это перестало быть метрикой теста, а стало метрикой билда, например? :) Ещё раз, если у меня 10000 тестов - какая мне разница, какой из них стал на N медленнее, если моя задача уложить тесты в X времени?

Ты открываешь тесты, профилируешь их, оптимизируешь там, где это проще сделать кодом, распараллеливаешь там, где не проще.

Для этого не нужна статистика, тебе интересно только _текущее_ состояние.

С тех пор, как это перестало быть метрикой теста, а стало метрикой билда, например? :) Ещё раз, если у меня 10000 тестов - какая мне разница, какой из них стал на N медленнее, если моя задача уложить тесты в X времени?

тоже вполне себе статистика в тестировании

Ну, если скорость работы сущностей, никак не связанных с тестированием - это статистика тестирования, то окей, я сдаюсь.

С тех пор, как это перестало быть метрикой теста, а стало метрикой билда, например? :) Ещё раз, если у меня 10000 тестов - какая мне разница, какой из них стал на N медленнее, если моя задача уложить тесты в X времени?

Это и есть метрика которая отслеживается.

если время прохождения билда с тестами не связано с тестированием, то я тоже:)

если время прохождения билда с тестами не связано с тестированием, то я тоже:)

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

Долгое время билда можно оптимизировать миллионом способов, лишь полтора из которых касаются тестов в принципе.

билда - прохождения тестов

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

билда - прохождения тестов

wut?

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

Я рад за гугл. Гугл ещё много чего делает, потому что может.

ну то есть гуглу можно потому что он "может")?

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

думаю это уже скатилось просто в холивар, так что закончу

Аргумент "в гугле так делают, поэтому я тоже буду" это такое себе.

Аргумент "в гугле так делают, поэтому я тоже буду" это такое себе.

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

Всем привет! Кто использует new relic? можете дать ссылку/подсказать? где понятно изложено как его установить и использовать?

Ох, это как раз таки отличный аргумент. Не делайте того, что не имеет смысла в ваших реалиях. Ваш кэп.

Всем привет! Кто использует new relic? можете дать ссылку/подсказать? где понятно изложено как его установить и использовать?

https://docs.newrelic.com/docs/apm/new-relic-apm/getting-started

Ох, это как раз таки отличный аргумент. Не делайте того, что не имеет смысла в ваших реалиях. Ваш кэп.

камон, с каких пор собирать статистику в тестировании и использовать - это только в реалиях гугла? хотя можешь не отвечать:)

камон, с каких пор собирать статистику в тестировании и использовать - это только в реалиях гугла? хотя можешь не отвечать:)

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

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

ты увидел агрумент, а должен был увидеть пример

у гугла есть возможность хранить тестовые результату 1.8 млн тестов на долгом времени, от такого факта я прям поражен был =)

и к флаки тестам у них другой подход

Окей. Пример Гугла прекрасен. Только: а) Это не значит, что это полезно всем. б) Зачем для этого метрики и статистика? Ты динамически собираешь тесты в билдплан на основе того, как они бегают? Нет, ты один раз проходишься профайлером по тестам, смотришь какие из них жрут много времени и приносят мало пользы, и выкидываешь их из первичных билдпланов. Всё

Для этого не нужна статистика, история последнего миллиарда тестов и чего-либо ещё.

Как ты пройдешь профайлером по 1.8 млн тестов? можешь до 1000 сократить даже. а) никто не говорит что полезно всем! может быть полезно б) чтобы не решать проблему с кучей тестов и профайлером динамически да, почему нет?

А в чем проблема пройтись профайлером по 1.8 млн. тестов? AFAIK это делается через запуск тест-рана с лишним флагом в конфиге. Я тебе по секрету скажу, люди профайлят приложения значительно большего объема. Приходится.

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

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

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

Ещё раз. Статистика нужна для тех данных которые: 1) Полезны только в history контексте. С производительностью тестов это не так. 2) К которым регулярно обращаются, т.е. проще наладить регулярный сбор данных, чем каждый раз это делать. В случае, если ты не собираешь новые билдпланы каждые 4 часа - это тоже не так.

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

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

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

Но, возможно я туповат.

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

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

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

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

вообще было бы очень хорошо. чтобы любой. кто хочет достичь дзена с получением статистики сказал это в ключе "У нас есть статистика %statistic%, она выявляет проблемы с %entity%, этот метод единственный\самый надежный для выявления проблемы %entity%, а затраты на реализацию этой статистики соизмеримо меньше %other_non_statistical_options%"

вообще было бы очень хорошо. чтобы любой. кто хочет достичь дзена с получением статистики сказал это в ключе "У нас есть статистика %statistic%, она выявляет проблемы с %entity%, этот метод единственный\самый надежный для выявления проблемы %entity%, а затраты на реализацию этой статистики соизмеримо меньше %other_non_statistical_options%"

а если статистика не выявляет проблем, то она плохая?

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

Да ну? А у вас не меряют среднее время выполнения, не оценивают время на тесты?

если чего-то из этой схемы у вас не будет сходиться, вероятно, вы оверинжинирите. Что дает статистика? Статистика ищет аномалии, показывает тренд. Грубо говоря это единственное, что вы можете описательно применить в графу составленному из величин. Либо резко все плохо, либо плохо становится постепенно.

ERROR: S client not available

а если статистика не выявляет проблем, то она плохая?

а зачем она в таком случае?

а зачем она в таком случае?

может проблем нет:)?

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

Да ну? А у вас не меряют среднее время выполнения, не оценивают время на тесты?

тимсити все сам померяет) но что-то я не помню, чтобы мне девиация в условные 20% на тестовы прогон была полезна

Что касается тренда - то тут все сложнее - с трендом вы примерно никогда ничего не поделаете.

ну и как бы да - время прохождения тестов, их статус - уже вполне статистика. и какая разница вы ее в Ci собираете или еще как-то. или я не прав?

анализ тренда упавших тестов это гадание на кофейной гуще

тимсити все сам померяет) но что-то я не помню, чтобы мне девиация в условные 20% на тестовы прогон была полезна

Прикольно. У меня нет тимсити. У меня есть тестрейл и джира. Мне надо проэстимейтить задачи в спринте. Успеваем протестить или нет. руками. Что будет мерять тимсити?

Прикольно. У меня нет тимсити. У меня есть тестрейл и джира. Мне надо проэстимейтить задачи в спринте. Успеваем протестить или нет. руками. Что будет мерять тимсити?

купи себе тимсити, вообще я говорил в контексте автотестов :)

потому что тред ушел в автотестовую статистику

Ну а я в общем контексте

изначально-то вопрос был "в общем"

про ручное — эстимейты полезны, а еще что?

код кваередж

точнее не так

тест кавередж

код кавередж ничего не показывает

и тех кто на него дрочит надо бить

тест каверадж лучше

а что такое тест кавередж?

но я не видел тест кавереджей не в хардкорном вотерфолле

в скрамбане на это молятся

а как измеряют?)

в скраме тоже много на что молятся, только часто оно не работает :)

интересно, каков подход

а как измеряют?)

Ну как обычно. Бюьт требования на блоки. каждый блок на функционал. каждый кусок функционала покрывают тестами. Согласовывают и утверждают. Считают за сотку.

люди добрые, отпишите плз где кто нашел удаленку( кроме как чата qa-вакансии, джина и хэдхантера)? желательно найти какую-нибудь проектную работу

Да, это не работает, потому что считают только позитивные тесты. Happy path

о, требования :)

люди добрые, отпишите плз где кто нашел удаленку( кроме как чата qa-вакансии, джина и хэдхантера)? желательно найти какую-нибудь проектную работу

Идите с этим в чат вакансий

((