Unit - тестирование с использованием gtest. Что должен включать в себя тест? (подробнее в описании)

Доброго всем времени суток.
Господа, требуется ваша помощь в разъяснении ряда терминов.
Имеется программа, реализующая алгоритм сортировки (думаю не столь важно какой).
Требуется написать 2 типа тестов для этой программы: тест производительности и тест корректности.
Но не совсем понятно, что включают в себя эти понятия.
В результате гугления получил обзорные представления о том как пишутся тесты.
Интуитивно догадываюсь, что тест производительности должен показать, сколько ресурсов потребляет программа, а корректности - правильный ли результат выдает.
Буду очень благодарен, если кто-нибудь поможет раскрыть суть данных терминов.

0

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

Нет, скорее с какой скоростью сортирует твоя сортировка например 10 миллионов элементов.

Сообщение от Pb-BASS а корректности - правильный ли результат выдает

Логично.

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

Сообщение от Pb-BASS тест производительности

Хотя это уже не юнит-тестирование.
А просто тест производительности.

1

А не подскажите тогда такие моменты, если не сложно.
Насколько верен подход проверки на корректность следующий способ.
Задать в качестве входного параметра некоторой сортирующей функции известный мне заранее массив, получить результат, а затем с помощью ASSERT_EQ проверить на равенство каждый элемент выходного массива с тем, что должно быть.

Сообщение от Azazel-San скорее с какой скоростью сортирует твоя сортировка

И как можно определить этот параметр.

0

Сообщение от Pb-BASS Насколько верен подход проверки на корректность следующий способ. Задать в качестве входного параметра некоторой сортирующей функции известный мне заранее массив, получить результат, а затем с помощью ASSERT_EQ проверить на равенство каждый элемент выходного массива с тем, что должно быть.

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

Сообщение от Pb-BASS И как можно определить этот параметр.

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

1

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

Вот да, это я и имел ввиду.

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

Сообщение от Azazel-San Вот и проверьте это

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

0

Сообщение от Pb-BASS Вот да, это я и имел ввиду.

Ну да, почему нет.
Еще наверное стоит сделать отдельные кейсы, если у вас сортировка работает не только с целыми числами.
Для более сложного варианта, можно контрольный сортировать каким-то, qsort из std.
Если вам вдруг зачем-то надо будет проверять на 10тыс. элементов.

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

Сообщение от Pb-BASS но проверить путем подсчета тактов процессора во время выполнения алгоритма?

Ну, почти
Если не забыл чего..
Вот здесь еще пример есть
А еще лучше заменить ctime на chrono

1

Кажется что-то стало прорисовываться. осталось только ответить на один вопрос: А причем тут gtest. Это вроде как и без него можно сделать.

0

Сообщение от Pb-BASS А причем тут gtest. Это вроде как и без него можно сделать.

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

1

Сообщение от Pb-BASS Требуется написать 2 типа тестов для этой программы: тест производительности и тест корректности. Но не совсем понятно, что включают в себя эти понятия.

1.
typical_work

Во-первых, и это очень важно, вам нужно понимать,
что именно вы собрались тестировать.

Юнит-тесты тестируют не программу.
Юнит тесты тестируют юнит.
Юнит - функция, класс, библиотека, etc.

Что значит "протестировать работу функции" ?
Это значит убедиться, что функция работает правильно.
Что нужно сделать для этого?
Нужно написать код, который запустит функцию правильным образом,
и посмотреть - отработала ли функция именно так,
как ожидалось.

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

Это первый и самый главный фундаментальным принцип TDD

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

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

Я называю такие тесты "тестами первой серии"
Или: "типичная работа"

2.
range

Тесты второй серии - это запуски юнита на различных пограничных входных данных.

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

И тд.

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

3.
invariant

Самые интересные, и самые сложные.

В программировании есть одно очень важное понятие.
Называется оно "инвариант".

Инвариант - это характеристика юнита (функции, класса, библиотеки, etc)
Которая характеризует способность юнита сохранять собственную работоспособность
независимо от корректности вызывающей стороны.

Если функцию запустить правильным образом, с правильными аргументами,
тогда она ожидаемо отработает правильно.

Но что, если функцию запустить неправильным образом,
или с неправильными аргументами?

Хорошая функция инвариантна.
То есть, она не должна сломаться только потому,
что ей скормили некорректные данные.

Третия серия тестов - это в каком то смысле попытки сломать юнит.
Будем запускать функцию с самыми дикими аргументами.
И самым диким образом.

Хороший юнит:
не должен сломаться,
не должен обрушить процесс.
не должен допустить порчи данных.

4.
death test

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

Вот специально для людей, которые с первого раза не слышат,
и им кажется, что проверок слишком много,
я повторю ещё раз: всегда и каждая

Каждая функция всегда должна проверить все входные аргументы.

Инвариантный юнит не доверяет никому и никогда.
Он в любой момент времени ожидает гадость от внешнего мира.
И всегда готов к защите.

Если возникла какая то проблема, то хороший юнит всегда найдет способ,
как предупрежить хозяина (программиста)


"Обработка ошибок" - это обширная тема для очень долгих разговоров.
Этой теме посвящены целые книги.

На практике же, как правило,
любой возможный подход сводится к 3м категориям:

4.1.
Коды ошибок, аварийные коллебеки

Нужно убедиться что юнит возвращает именно тот код ошибки,
какой мы ожидаем для каждой конкретной ситуации.

С коллебками аналогично.
убеждаемся, что для каждой конкретной ситуации
будет своевременно запущен соответствующий коллбек.

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

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

4.3.
Смертельный тест.

Программные ошибки - ошибки, которых быть не должно.
Не должно быть вообще, и в принципе.

Проверка "не сбыточных" условий - компетенция assert

При помощи assert достигается разумный баланс
между надежностью (количеством проверок всего и всея)
и производительностью (скорость работы)

Ассертам можно посвятить целую главу в какой ни будь книге.

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

Сработавший ассерт - смерть процесса.

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

Тест, результат которого - гибель процесса, называется "смертельным".

Ещё к юниту могут быть такие требования:
"лучше процесс не сделает ничего, чем сделает неправильно"

Допустим, наш поток захватывает мутекс.
И оказывается, что мутекс - брошенка.

Что это значит? Это значит, что мутекс был разблокирован системой.
А что значит системой? Значит его предыдущий владелец не разлочил его.
А почему не разлочил? Потому что что-то не хорошее случилось.
Например, его прежний владелец не успел разлочить мутекс,
потому что крашнулся на половине пути.


А у нас тут банковское ПО, и все основания полагать,
Что случилось что-то плохое.
И черт его знает в каком состоянии теперь находятся оберегаемые мутексом данные.

В этой непростой ситуации маленькому юниту придётся принимать решение за всю программу.
Юнит не может позволить нестабильному процессу продолжать жить.
Если юнит не остановит процесс "здесь",
тогда "там" (а "там" ещё даже могут не подозревать об аварии) может таких дров наломать.

В подобной ситуации некоторые юниты обязаны совершить самоубийство (std::terminate)

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

-------------------

5.
Стресс-тесты.

Все предыдущие виды тестов исскуственно воспроизводили различные ситуации.

В боевых условиях могут возникать какие угодно сочетания событий.
Многие из которых могут быть далеки от исскуственно воссозданных.

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

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

Или нужно протестировать тред-пул.
Тред-пул - механизм для работы с потоками.
На тестах всегда всё хорошо.
А на бою произошло зависание (предположительно дедлок)

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

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

Планировщик задач системы начал выдавать потокам кванты времени сильно неравномерно.
В результате первыми обычно отказывают таймеры.

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

Что бы выявить подобные "уязвимости",
необходимо запускать тесты в самых разных условиях.
Под нагрузкой и без нагрузки.
И по много-много раз.

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

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


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

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

6.
Производительность.

Однажды, на одном из форумов, один парень привел такой код:
https://ideone.com/7zvVjP

В своей теме он написал:

Обнаружил, что обращение к полям структуры через обыкновенный указатель медленнее, чем через shared_ptr Возможно тест не совсем корректен? Если да, то прошу, поправьте меня

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

Почему так получается?

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

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

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

Что бы не получилось, как у того парня.
Нельзя тестировать производительность "двух разных циклов" в одной программе.
Нельзя запускать два разных теста в одной программе.

Для функции сортировки бенчмарк:
perfomans_1.exe время сортировки массива из 1 элемента
perfomans_10.exe время сортировки массива из 10 элементов
...
perfomans_1000000.exe время сортировки массива из 1'000'000 элементов

Каждая из этих программ в результате своей работы
вернет длительность работы функции сортировки в миллисекундах

Берем perfomans_1.exe, и в цикле запускаем его 1'000'000,
Фиксируем среднее время работы функции (не процесса!).

Потом берем perfomans_10.exe, и по аналогии.
И так же с остальными.

7.
Сравнительные тесты.

Тесты производительности любят сравнения.

Рядышком с perfomans_1.exe нужно положить какой ни будь perfomans_1_std.exe
который делает суть тоже самое,
только там используется какая ни будь стандартная qsort


По итогам тестов обычно делают сводную табличку,
с результатами замеров.

И уже можно делать выводы о качестве тестируемого инструмента.

3