А есть возможность смотреть историю тестов, выполняемых локально, т.е. в студии?
Посмотреть время последнего запуска тестов, например? Ну т.е. все запуски, успешно\не успешно, время и т.п.
в ретроспективе?
ЗЫ: Еще есть дико бесячая бага\фича, что если в тесте срабатывает Debug.Assert, то все дерево тестов
разносит нафиг. Т.е. становится не аккуратное дерево, а какая-то жуть
Здравствуйте, Sharov, Вы писали:
S>А есть возможность смотреть историю тестов, выполняемых локально, т.е. в студии? S>Посмотреть время последнего запуска тестов, например? Ну т.е. все запуски, успешно\не успешно, время и т.п. S>в ретроспективе?
Нет, нельзя. А каков сценарий? Зачем знать, что тест когда-то падал в процессе?
S>ЗЫ: Еще есть дико бесячая бага\фича, что если в тесте срабатывает Debug.Assert, то все дерево тестов S>разносит нафиг. Т.е. становится не аккуратное дерево, а какая-то жуть
Очень любопытно, отнесу в QA. Прям просто написать в любом тесте Debug.Assert?
Здравствуйте, qxWork, Вы писали:
S>>А есть возможность смотреть историю тестов, выполняемых локально, т.е. в студии? S>>Посмотреть время последнего запуска тестов, например? Ну т.е. все запуски, успешно\не успешно, время и т.п. S>>в ретроспективе? W>Нет, нельзя. А каков сценарий? Зачем знать, что тест когда-то падал в процессе?
Почему падал? Банально хранить инф-ию о 10,20,... последних запусков -- общее время, какие упали и т.п. вещи.
S>>ЗЫ: Еще есть дико бесячая бага\фича, что если в тесте срабатывает Debug.Assert, то все дерево тестов S>>разносит нафиг. Т.е. становится не аккуратное дерево, а какая-то жуть W>Очень любопытно, отнесу в QA. Прям просто написать в любом тесте Debug.Assert?
Стек еще поглубже сделать и на крайний случай в каком-нибудь отдельном task'е. Ну т.е.
чтобы это в какой-то подзадаче случилось. Но можно и так попробовать.
Здравствуйте, Sharov, Вы писали:
S>Почему падал? Банально хранить инф-ию о 10,20,... последних запусков -- общее время, какие упали и т.п. вещи.
Сохранить не сложно. Но я не понимаю юзкейса: как эта информация будет использоваться. И для чего.
S>Стек еще поглубже сделать и на крайний случай в каком-нибудь отдельном task'е. Ну т.е. S>чтобы это в какой-то подзадаче случилось. Но можно и так попробовать. Воспроизвели, починили и скоро зальем
Здравствуйте, qxWork, Вы писали:
S>>Почему падал? Банально хранить инф-ию о 10,20,... последних запусков -- общее время, какие упали и т.п. вещи. W>Сохранить не сложно. Но я не понимаю юзкейса: как эта информация будет использоваться. И для чего.
Банально посмотреть как бегал предыдущий тестовый запуск -- время, кол-во ошибочных тестов и какие именно, и т.д.
Краткое резюме пред. запусков (последних 5-10 или хотя бы самого последнего). Т.е. чтобы эта инф-ия была доступна
и после перезапуска студии.
Здравствуйте, Sharov, Вы писали:
S>Банально посмотреть как бегал предыдущий тестовый запуск -- время, кол-во ошибочных тестов и какие именно, и т.д. S>Краткое резюме пред. запусков (последних 5-10 или хотя бы самого последнего). Т.е. чтобы эта инф-ия была доступна S>и после перезапуска студии.
Посмотреть чтобы что? Что там хочется увидеть и что в зависимости от увиденного делать?
Здравствуйте, qxWork, Вы писали:
S>>Банально посмотреть как бегал предыдущий тестовый запуск -- время, кол-во ошибочных тестов и какие именно, и т.д. S>>Краткое резюме пред. запусков (последних 5-10 или хотя бы самого последнего). Т.е. чтобы эта инф-ия была доступна S>>и после перезапуска студии. W>Посмотреть чтобы что? Что там хочется увидеть и что в зависимости от увиденного делать?
Ну хотя бы статистику глянуть по всем или только последним тестам. Банально, мне надо было оценить
время тестового прогона, я давно тесты не гонял, студия перезагружалась, инф-ии нет. Мне это время
было нужно чтобы запланировать др. деятельность -- запустил тесты, вышел в магазин, например.
Если это проблематично, то я, мягко говоря, не сильно настаиваю. Каких-то сильно полезных сценариев
я придумать не могу. Просто пришлось сидеть и ждать, пока все закончится. А так глянул, оценил и
спланировал некую деятельность.
Здравствуйте, Sharov, Вы писали:
S>Ну хотя бы статистику глянуть по всем или только последним тестам. Банально, мне надо было оценить S>время тестового прогона, я давно тесты не гонял, студия перезагружалась, инф-ии нет. Мне это время S>было нужно чтобы запланировать др. деятельность -- запустил тесты, вышел в магазин, например.
Что ж за тесты такие, что можно в магазин сходить пока они идут? И зачем такие долгие запускать локально, если есть CI?
Я не стебусь, я правда пытаюсь понять сценарий использования.
S>Если это проблематично, то я, мягко говоря, не сильно настаиваю. Каких-то сильно полезных сценариев S>я придумать не могу. Просто пришлось сидеть и ждать, пока все закончится. А так глянул, оценил и S>спланировал некую деятельность.
Сделать можно все, что угодно. Но делать то, что будет нужно одному человеку, да и то по праздникам, точно смысла не имеет.
А с тестами что-то не то, если они такие медленные, да еще и вы об этом не в курсе.
Здравствуйте, qxWork, Вы писали:
W>Здравствуйте, Sharov, Вы писали:
S>>Ну хотя бы статистику глянуть по всем или только последним тестам. Банально, мне надо было оценить S>>время тестового прогона, я давно тесты не гонял, студия перезагружалась, инф-ии нет. Мне это время S>>было нужно чтобы запланировать др. деятельность -- запустил тесты, вышел в магазин, например. W>Что ж за тесты такие, что можно в магазин сходить пока они идут? И зачем такие долгие запускать локально, если есть CI?
Ну например тесты, которые запускают какой-то мат. движок для вычисления чего-то, инвертирование
огромной матрицы и таких тестов не мало. Как вариант.
Вроде сразу все коммитить в CI не прогнав локально считается признаком плохого тона. Тем более если
коммит идет в master.
W>Я не стебусь, я правда пытаюсь понять сценарий использования.
Выше же писал, простенькую статистику по запускам. Тут правда действительно будет нелепица, если
после, например, рефакторинга куча тестов окажется не нужными. Т.е. полный слом статистики получается.
Т.е. мой сценарий хорош на случай, когда кол-ов тестов не меняется или растет. Хотя может это и
надуманная проблема.
S>>Если это проблематично, то я, мягко говоря, не сильно настаиваю. Каких-то сильно полезных сценариев S>>я придумать не могу. Просто пришлось сидеть и ждать, пока все закончится. А так глянул, оценил и S>>спланировал некую деятельность. W>Сделать можно все, что угодно. Но делать то, что будет нужно одному человеку, да и то по праздникам, точно смысла не имеет.
Я вообще не настаиваю, я прекрасно понимаю уровень нагрузки. Я думал, что может где-то все же есть такая инф-ия.
Нет, ну и ладно. Это совсем не всегда нужно.
W>А с тестами что-то не то, если они такие медленные, да еще и вы об этом не в курсе.
Да в курсе я. Выше написал сценарий. Плюс, например, раньше была параллельная версия, когда каждое
ядро проц. обрабатывало один вектор, то, например, я переделал все на последовательный вариант.
Еще в разы (~на кол-во ядер) медленнее.
Здравствуйте, Sharov, Вы писали:
S>Ну например тесты, которые запускают какой-то мат. движок для вычисления чего-то, инвертирование S>огромной матрицы и таких тестов не мало. Как вариант. S>Вроде сразу все коммитить в CI не прогнав локально считается признаком плохого тона. Тем более если S>коммит идет в master.
Коммит в бранч и на CI. Если все зеленое, то льем в мастер — нет, чиним то, что упало и повторяем. CI обычно умеет показать и времена тоже.
Честно, пока это выглядит каким-то очень специальным случаем.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Вроде сразу все коммитить в CI не прогнав локально считается признаком плохого тона. НС>Кем считается? Почему?
Ситуация, когда человек сломал билд (тесты) и при этом такая же проблема у него возникла бы
и на локальной машине, кажется мне неправильной. Как минимум лишний расход ресурсов и увеличение энтропии.
А так лет 10 назад, мне советовали локально прогонять тесты и если все ок, делать push.
S>> Тем более если коммит идет в master. НС>Вот коммит в мастер это точно признак плохого тона.
Знаю, да. Но если один работаешь или до первой какой-нибудь беты, то почему бы нет?
Здравствуйте, Sharov, Вы писали:
S>Ситуация, когда человек сломал билд (тесты) и при этом такая же проблема у него возникла бы S>и на локальной машине, кажется мне неправильной.
Почему?
S> Как минимум лишний расход ресурсов и увеличение энтропии.
Это звучит как бред. Какая разница, с точки зрения расхода ресурсов, на локальной машине тест гоняется или на билд-агенте? Если тебе так уж хочется получить тормоза на машине разработки — ты всегда можешь поставить на ней агента, и явно указать его для своих сборок.
S>А так лет 10 назад, мне советовали локально прогонять тесты и если все ок, делать push.
Глупость тебе советовали, даже 10 лет назад глупость. А уж в 2021 году ...
S>>> Тем более если коммит идет в master. НС>>Вот коммит в мастер это точно признак плохого тона. S>Знаю, да. Но если один работаешь или до первой какой-нибудь беты, то почему бы нет?
Тут уж либо крестик сними, либо трусы одень. Либо сырые коммиты в мастер создают проблемы, и тогда это дурной тон, либо они проблем не создают, тогда и проблем с сырыми коммитами в мастер тоже нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Как минимум лишний расход ресурсов и увеличение энтропии. НС>Это звучит как бред. Какая разница, с точки зрения расхода ресурсов, на локальной машине тест гоняется или на билд-агенте? Если тебе так уж хочется получить тормоза на машине разработки — ты всегда можешь поставить на ней агента, и явно указать его для своих сборок.
Почему сразу бред? Во-первых,отъедаются ресурсы, генерируется репорты, алармы и т.п., и самое главное, в гит находится некорректный код.
Я сейчас имею в виду коммит в dev_branch. С feature_branch и правда особых проблем нет. Только если ресурсы, тем более
если это облачный СI.
Речь не идет о каких-то нереальных нагрузочных тестах или взаимодействии сервисов, т.е. где надо кучу всего
разворачивать, речь идет о юнит-тестах на 10-20 мин. .
Здравствуйте, Sharov, Вы писали:
НС>>Это звучит как бред. Какая разница, с точки зрения расхода ресурсов, на локальной машине тест гоняется или на билд-агенте? Если тебе так уж хочется получить тормоза на машине разработки — ты всегда можешь поставить на ней агента, и явно указать его для своих сборок.
S>Почему сразу бред?
Потому что не стыкуется с логикой.
S> Во-первых,отъедаются ресурсы,
А на локальной машине они не отъедаются что ли?
S>и самое главное, в гит находится некорректный код.
Почему самое главное? Что в этом плохого?
S>Я сейчас имею в виду коммит в dev_branch. С feature_branch и правда особых проблем нет.
Я не понимаю что такое dev_branch и почему туда некорректный код проблема. Но если проблема — просто не надо туда коммитить напрямую, без тестов.
S>Речь не идет о каких-то нереальных нагрузочных тестах или взаимодействии сервисов, т.е. где надо кучу всего S>разворачивать, речь идет о юнит-тестах на 10-20 мин. .
И все это время ты будешь терпеть тормоза на своей машине? Интересное у тебя понимание об экономии ресурсов.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Во-первых,отъедаются ресурсы, НС>А на локальной машине они не отъедаются что ли?
Отъедаются, но помимо меня могут быть еще люди. Т.е. если можно проблему выловить локально, почему нет?
S>>и самое главное, в гит находится некорректный код. НС>Почему самое главное? Что в этом плохого?
У всех из-за меня упадут тесты.
S>>Я сейчас имею в виду коммит в dev_branch. С feature_branch и правда особых проблем нет. НС>Я не понимаю что такое dev_branch и почему туда некорректный код проблема. Но если проблема — просто не надо туда коммитить напрямую, без тестов.
dev_branch -- это которая вместо master'а, development.
S>>Речь не идет о каких-то нереальных нагрузочных тестах или взаимодействии сервисов, т.е. где надо кучу всего S>>разворачивать, речь идет о юнит-тестах на 10-20 мин. . НС>И все это время ты будешь терпеть тормоза на своей машине? Интересное у тебя понимание об экономии ресурсов.
Ну какие такие особые ресурсы нужны для веб серфинга или КЫВТ'а? Ну или отойду куда-нибудь, пройдусь, разминка или
еще что-нибудь. Долгую компиляцию на своих машинах люди же как-то переживают.
Здравствуйте, Sharov, Вы писали:
S>>> Во-первых,отъедаются ресурсы, НС>>А на локальной машине они не отъедаются что ли? S>Отъедаются, но помимо меня могут быть еще люди.
Так и билдагентов, надеюсь, у вас больше одной штуки, не?
S> Т.е. если можно проблему выловить локально, почему нет?
Потому что нелокально тесты гонять удобнее.
S>>>и самое главное, в гит находится некорректный код. НС>>Почему самое главное? Что в этом плохого? S>У всех из-за меня упадут тесты.
У кого у всех? Зачем кому то из твоей ветки запускать тесты?
S>>>Я сейчас имею в виду коммит в dev_branch. С feature_branch и правда особых проблем нет. НС>>Я не понимаю что такое dev_branch и почему туда некорректный код проблема. Но если проблема — просто не надо туда коммитить напрямую, без тестов. S>dev_branch -- это которая вместо master'а, development.
Ну значиттуда не надо коммитить напрямую.
НС>>И все это время ты будешь терпеть тормоза на своей машине? Интересное у тебя понимание об экономии ресурсов. S>Ну какие такие особые ресурсы нужны для веб серфинга или КЫВТ'а? S> Ну или отойду куда-нибудь, пройдусь, разминка или S>еще что-нибудь.
Работу работать, как я понимаю, не вариант?
S> Долгую компиляцию на своих машинах люди же как-то переживают.
Да не особо, судя по тому что сервера для компиляции довольно популярны.
