Идеи и советы для временного юнит-тестирования?

Question

Кто-нибудь делал временное юнит-тестирование?

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

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

Спасибо

Редактировать: Попытка составить список вещей, которые необходимо позаботиться в такой ситуации

Answer 1

Просто некоторые заметки из моего опыта ... Мы заботимся о производительности многих наших компонентов и имеем очень похожую на unittest среду для их тренировки и определения времени (задним числом мы должны были просто использовать CppUnit или boost::test как мы делаем для юнит-тестов). Мы называем эти «тесты компонентов», а не юнит-тесты.

• Мы не указываем верхний предел времени, а затем проходим / не выполняем ... мы просто регистрируем время (это отчасти связано с нежеланием клиента фактически предъявлять жесткие требования к производительности, несмотря на то, что производительность - это то, что их волнует много!). (Мы пытались пройти / потерпеть неудачу в прошлом, и у нас был плохой опыт, особенно на машинах разработчика ... слишком много ложных тревог, потому что пришло письмо или что-то индексировалось в фоновом режиме)
• Разработчики, работающие над оптимизацией, могут просто работать над сокращением времени выполнения тестов без необходимости создавать целую систему (почти так же, как тесты юнитов позволяют сосредоточиться на одном бите кодовой базы).
• Большинство тестов тестируют несколько итераций итераций чего-либо. Ленивое создание ресурсов может означать, что первое использование компонента может иметь значительно больше «времени установки», связанного с ним. Мы выходим из системы «1-е», «среднее последующее» и «среднее за все» время. Убедитесь, что вы понимаете причину каких-либо существенных различий между ними. В некоторых случаях мы устанавливаем время установки явно в качестве отдельного случая.
• Должно быть очевидным, но: просто время, которое вам действительно нужно, а не время настройки тестовой среды!
• Для тестов вы в конечном итоге тестируете «реальные» случаи гораздо больше, чем в юнит-тестах, поэтому настройка теста и время выполнения теста, как правило, на лот дольше.
• У нас есть машина для автоматического тестирования, которая запускает все тесты каждую ночь и публикует журнал всех результатов. Теоретически, мы могли бы построить график или пометить компоненты, которые упали ниже целевой производительности. На практике у нас нет времени на то, чтобы настроить что-либо подобное.
• Вы хотите, чтобы такая машина для автоматического тестирования была полностью свободна от других обязанностей (например, если это также ваш SVN-сервер, кто-то, делающий большую проверку, будет выглядеть так, как будто у вас был огромный спад производительности).
• Подумайте о других скалярных величинах, которые вы, возможно, захотите сравнить, кроме времени, и планируйте поддерживать их с самого начала. Например, «достигнута степень сжатия», «Skynet AI IQ» ...
• Не позволяйте людям анализировать данные тестов на оборудовании с минимальными техническими характеристиками. Я видел потерянное время, потому что проектное решение было принято в результате теста производительности чьей-то нежелательной ошибки, когда запуск на целевой платформе - высокопроизводительном сервере - показал бы что-то совершенно другое!

Answer 2

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

Answer 3

Я думаю, вы могли бы проводить регрессионные проверки по показателям времени выполнения юнит-теста. С помощью множества платформ модульных тестов вы обычно можете получить отчет, в котором указано имя теста, время выполнения. Я знаю, что junit / surefire это делает. Таким образом, вы можете сравнить это с предыдущими прогонами и установить, произошли ли какие-либо существенные изменения. Если вы храните все это в базе данных (с именем хоста), вы можете сравнить время выполнения для той же среды выполнения с предыдущими тестовыми запусками. Таким образом, вы не пишете тесты на производительность. но вы просто утверждаете отдельно, что существенных изменений во времени выполнения не было.

Answer 4

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

Answer 5

Если вы работаете в C ++, взгляните на http://unittest -cpp.sourceforge.net /

Я не использовал материал времени, но это лучший (самый лаконичный) фреймворк для модульных тестов, который я нашел.