Что делать, если юнит-тесты выполняются все дольше?

@Etyuhibosecyu · Регистрация: 13.07.2017

Студворк — интернет-сервис помощи студентам

Например, у меня есть библиотеки Ares F, Ares I и Ares T, которые составляют части единой системы - Ares Tools, и имеют мало смысла в отрыве от этой системы, так что логично их проверять вместе. И вот, сначала тесты только для Ares T (который тогда включал в себя то, что позже стало Ares F) занимали до 8 минут. При добавлении проверок для Ares I уже стало до 19 минут. А сегодня длительность всех проверок на распаковку составила ровно 20 минут! И это - "чистое" время, без учета накладных расходов на работу самой системы тестирования, и также в это время не включен PPM, иначе страшно даже представить, каким будет время прохождения тестов. Что с этим можно сделать? Ответ "уменьшить количество проверок" не принимается. Если убрать тормоза в методах - то в Лемпеле-Зиве они и так убраны, а в BWT главный тормоз - сортировка, и я не знаю, как ее ускорить. Уже и так ускорена многократно. Есть ли какой-то выход?

@OwenGlendower · 13.07.2024, 22:01

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

@Etyuhibosecyu · 13.07.2024, 22:13 **[ТС]**

Сообщение от OwenGlendower

то просто уменьшите размеры данных.

А как быть, если эти данные - например, изображение, размер которого уменьшить нельзя?

Добавлено через 10 минут

Сообщение от Etyuhibosecyu

изображение, размер которого уменьшить нельзя?

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

@OwenGlendower · 13.07.2024, 22:22

Сообщение от Etyuhibosecyu

размер которого уменьшить нельзя?

Почему нельзя?

Сообщение от Etyuhibosecyu

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

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

@Usaga · 14.07.2024, 09:17

Etyuhibosecyu, по мимо озвученных выше советов еще добавлю, что долгое выполнение тестов не всегда является проблемой. Если тестов много, если данные большие и уменьшить их нельзя. Можно тесты выполнять параллельно. Оптимизировать тесты попробовать. Машину помощнее взять. Или смириться.

В твоем случае я почти наверняка уверен, что тесты адово сделаны и выполняют лишнюю работу, гоняя слишком много данных.

@Rius · 14.07.2024, 09:50

Сообщение от Usaga

В твоем случае я почти наверняка уверен, что тесты адово сделаны

Не только тесты, но и тестируемый код.

@OwenGlendower · 14.07.2024, 17:52

Сообщение от Usaga

В твоем случае я почти наверняка уверен, что тесты адово сделаны и выполняют лишнюю работу, гоняя слишком много данных.

У меня аналогичное ощущение после того как увидел примеры его бенчмарков (раз, два). Каждый раз большие объемы данных хотя явно можно было обойтись меньшими. Большие, если сильно хочется, можно оставить для стресс-тестов.

@kolorotur · 17.07.2024, 17:10

Сообщение от Etyuhibosecyu

А как быть, если эти данные - например, изображение, размер которого уменьшить нельзя?

А почему его нельзя уменьшить?
Юнит-тесты же должны проверять корректность алгоритма. Какая алгоритму разница: 100500х100500 изображение или 20х20?

@Etyuhibosecyu · 17.07.2024, 17:17 **[ТС]**

Сообщение от kolorotur

Какая алгоритму разница: 100500х100500 изображение или 20х20?

Причем тут 100500? Речь о проверке корректности на изображениях разной структуры. А изображений нужной структуры 20x20 я себе не представляю.

@kolorotur · 17.07.2024, 17:35

Сообщение от Etyuhibosecyu

Причем тут 100500?

При том, что я не знаком с вашим алгоритмом, но видя слово "изображение" думаю об алгоритмах, работающих с изображениями. Всем знакомым мне алгоритмам без разницы какой размер изображения.

Сообщение от Etyuhibosecyu

Речь о проверке корректности на изображениях разной структуры. А изображений нужной структуры 20x20 я себе не представляю.

Что за структура?

@Etyuhibosecyu · 17.07.2024, 17:56 **[ТС]**

Сообщение от kolorotur

При том, что я не знаком с вашим алгоритмом, но видя слово "изображение" думаю об алгоритмах, работающих с изображениями.

Это алгоритм сжатия изображений.

Сообщение от kolorotur

Что за структура?

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

@kolorotur · 17.07.2024, 18:06

Сообщение от Etyuhibosecyu

Это алгоритм сжатия изображений.

Зачем для тестирования огромные изображения?

Сообщение от Etyuhibosecyu

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

Чем определяется конкретный способ сжатия?

@Etyuhibosecyu · 17.07.2024, 18:10 **[ТС]**

Сообщение от kolorotur

Зачем для тестирования огромные изображения?

Они не огромные, просто некоторые такие, что программа над ними долго думает. По структуре неудобные для программы.

Сообщение от kolorotur

Чем определяется конкретный способ сжатия?

Обход, дельта, Лемпель-Зив или BWT...

@kolorotur · 17.07.2024, 18:36

Сообщение от Etyuhibosecyu

Они не огромные, просто некоторые такие, что программа над ними долго думает.

Если данные небольшие и программа с ними висит, то это проблема не в юнит-тестах, а в алгоритме.
Т.е. тема не имеет смысла.

Сообщение от Etyuhibosecyu

Обход, дельта, Лемпель-Зив или BWT

LZW — это же сжатие. Вы сжимаете изображение для того, чтобы определить какой способ сжатия использовать?
Хотя, это не важно: для этих методов тоже можно использовать небольшие данные — вы же корректность алгоритма проверяете, а не бенчмарк делаете.

@Etyuhibosecyu · 17.07.2024, 18:44 **[ТС]**

Сообщение от kolorotur

Если данные небольшие и программа с ними висит, то это проблема не в юнит-тестах, а в алгоритме.

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

Сообщение от kolorotur

LZW — это же сжатие.

Очень слабое сжатие.

Сообщение от kolorotur

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

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

Сообщение от kolorotur

Хотя, это не важно: для этих методов тоже можно использовать небольшие данные — вы же корректность алгоритма проверяете, а не бенчмарк делаете.

Корректность алгоритма важно проверить на разных данных. Бывают случаи, когда на одних данных алгоритм корректен, а на других - нет.

@Pilarentes · 17.07.2024, 18:47

Сообщение от Etyuhibosecyu

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

здесь требуется пояснение

Сообщение от Etyuhibosecyu

Бывают случаи, когда на одних данных алгоритм корректен, а на других - нет.

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

@Etyuhibosecyu · 17.07.2024, 18:49 **[ТС]**

Сообщение от Pilarentes

это что же, ваше приложение может похерить

Просто распаковка вылетит и все.

@kolorotur · 18.07.2024, 10:29

Сообщение от Etyuhibosecyu

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

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

Сообщение от Etyuhibosecyu

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

Это очевидно.
Вопрос был про способ выбора метода сжатия в зависимости от передаваемого изображения.

Сообщение от Etyuhibosecyu

Корректность алгоритма важно проверить на разных данных. Бывают случаи, когда на одних данных алгоритм корректен, а на других - нет.

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

@Wolfdp · 19.07.2024, 15:40

Ммм... если ваши алгоритмы не подразумевают разную логику для разрешений 100500х100500 и 1000х1000, возможно стоит сделать следующий финт ушами:
- флаг указывающий что тестируем "по максимум"
- на вход сделать как 1000х100, так и 100500х100500
- в процессе разработки проверять урезанным вариантом.
- по завершению запускать уже весь прогон.

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

@HF · 19.07.2024, 18:27

Сообщение от Wolfdp

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

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

Если блин есть желание проверить огромный файл, то просто нужно взять и скомпилировать консольную программу. Запустить в командной строке, сгенерить огромный файл, потом прочитать из результата (файла) нужные параметры (размеры, заголовки, куски байт и т.п.). Ну а если результат должен быть всегда идентичный, то вообще можно два файла сравнивать. В чём проблема не понятно.

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@Etyuhibosecyu Труд вопреки насмешкам 416 / 181 / 41 Регистрация: 13.07.2017 Сообщений: 4,777 Записей в блоге: 14

	.NET 8 Что делать, если юнит-тесты выполняются все дольше? 13.07.2024, 21:12. Показов 1575. Ответов 21 Метки нет (Все метки) Например, у меня есть библиотеки Ares F, Ares I и Ares T, которые составляют части единой системы - Ares Tools, и имеют мало смысла в отрыве от этой системы, так что логично их проверять вместе. И вот, сначала тесты только для Ares T (который тогда включал в себя то, что позже стало Ares F) занимали до 8 минут. При добавлении проверок для Ares I уже стало до 19 минут. А сегодня длительность всех проверок на распаковку составила ровно 20 минут! И это - "чистое" время, без учета накладных расходов на работу самой системы тестирования, и также в это время не включен PPM, иначе страшно даже представить, каким будет время прохождения тестов. Что с этим можно сделать? Ответ "уменьшить количество проверок" не принимается. Если убрать тормоза в методах - то в Лемпеле-Зиве они и так убраны, а в BWT главный тормоз - сортировка, и я не знаю, как ее ускорить. Уже и так ускорена многократно. Есть ли какой-то выход? 0

@OwenGlendower Администратор 18311 / 14235 / 5368 Регистрация: 17.03.2014 Сообщений: 28,905 Записей в блоге: 1
	13.07.2024, 22:01
	Etyuhibosecyu, переписать тесты так чтобы они не занимали столько времени. Ответ в стиле Капитана Очевидность, но ничего другого тут нечего предложить. Если ваши юнит-тесты написаны так же как и бенчмарки, то просто уменьшите размеры данных. В юнит-тестах нет смысла использовать экстремально высокие значения. 0

@Usaga 14321 / 9411 / 1356 Регистрация: 21.01.2016 Сообщений: 35,481
	14.07.2024, 09:17
	Etyuhibosecyu, по мимо озвученных выше советов еще добавлю, что долгое выполнение тестов не всегда является проблемой. Если тестов много, если данные большие и уменьшить их нельзя. Можно тесты выполнять параллельно. Оптимизировать тесты попробовать. Машину помощнее взять. Или смириться. В твоем случае я почти наверняка уверен, что тесты адово сделаны и выполняют лишнюю работу, гоняя слишком много данных. 0

@Wolfdp 3790 / 1767 / 371 Регистрация: 15.06.2012 Сообщений: 6,543 Записей в блоге: 3
	19.07.2024, 15:40
	Ммм... если ваши алгоритмы не подразумевают разную логику для разрешений 100500х100500 и 1000х1000, возможно стоит сделать следующий финт ушами: - флаг указывающий что тестируем "по максимум" - на вход сделать как 1000х100, так и 100500х100500 - в процессе разработки проверять урезанным вариантом. - по завершению запускать уже весь прогон. p.s. в идеале юнит тесты должны проверять граничные значения, и мне слабо понятно как это колериюет с объемом. Т.е. сжать полностью одноцветное изображение, из разных пикселей, градиент, шахматным порядком -- кажись это имеет смысл. А скармливать большие объемы уже ближе к бенчмаркам. 1