Unit test скорость выполнения (сколько тестов в секунду?)

Ответ 1

Все модульные тесты должны работать под вторым (все комбинированные тесты должны выполняться через 1 секунду). Теперь я уверен, что это имеет практические ограничения, но у меня был проект с 1000 тестов, которые быстро выполняются на ноутбуке. Вы действительно хотите эту скорость, чтобы ваши разработчики не боялись рефакторинга какой-то основной части модели (т.е. Lemme приготовят кофе, пока я запускаю эти тесты... через 10 минут он возвращается).

Это требование также заставляет вас правильно проектировать ваше приложение. Это означает, что ваша модель домена является чистой и содержит нулевые ссылки на любой тип стойкости (File I/O, Database и т.д.). Единичные тесты касаются тестирования этих деловых отношений.

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

Ответ 2

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

Ответ 3

Цель - 100 секунд тестов в секунду. То, как вы туда попадаете, - это следующие правила модульных тестов: .

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

Ответ 4

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

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

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

Ответ 5

Точка данных - тесты регрессии Python

Вот цифры на моем ноутбуке для запуска "make test" для Python 2.5.2:

• количество тестов: 3851 (приблизительный)
• время выполнения: 9 мин, 6 секунд
• скорость выполнения: 7 тестов/сек

Ответ 6

В настоящее время мы проводим 270 тестов примерно за 3. секунды. Вероятно, около 8 тестов, которые выполняют файл IO.

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

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

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

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

Ответ 7

Я оцениваю свои модульные тесты на основе каждого теста, а не по количеству тестов в секунду. Скорость, на которую я нацелен, составляет 500 мс или меньше. Если он выше этого, я рассмотрю тест, чтобы узнать, почему он так долго.

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

Ответ 8

хорошая статья об этом от Power Of Two, авторы UnitTest ++.

Ответ 9

Сколько времени слишком долго для человека unit test?

Я бы сказал, это зависит от скорости компиляции. Обычно выполняется каждый тест на каждом компиляторе. Цель модульного тестирования заключается не в замедлении, а в том, чтобы принести сообщение "ничего не сломано, продолжайте" (или "что-то сломалось, STOP" ).

Я не беспокоюсь о скорости выполнения теста, пока это не начинает раздражать.

Опасность состоит в том, чтобы прекратить выполнение тестов, потому что они слишком медленные.

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

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

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

Ответ 10

Некоторые фреймворки обеспечивают автоматическое выполнение конкретных модульных тестов на основе эвристик, таких как последнее модифицированное время. Для Ruby и Rails AutoTest обеспечивает гораздо более быстрое и гибкое выполнение тестов. Когда я сохраняю модель Rails app/models/foo.rb, выполняются соответствующие модульные тесты в test/unit/foo_test.rb.

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

Ответ 11

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

Сколько времени для отдельного unit test?

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

Какую скорость выполнения вы планируете выполнять с помощью своих модульных тестов (# тест в секунду)?

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

В настоящее время мы имеем около 800 тестов, которые работают менее чем за 30 секунд, около 27 тестов в секунду. Это включает время запуска мобильного эмулятора, необходимого для их запуска. Большинство из них принимают 0-5 мс (если я правильно помню).

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

У нас также есть настраиваемый тайм-аут, установленный на 5 секунд - все, что займет больше времени, не будет выполнено.