Скорость выполнения модульных тестов (сколько тестов в секунду?)

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

Мне было бы интересно узнать, есть ли у людей какие-либо конкретные пороги для определения того, являются ли их тесты слишком медленными, или это просто, когда трения долго работающего набора тестов одолевают вас?

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

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


Сводка ответов: Спасибо за отличные ответы. Большинство советов, кажется, не беспокоиться о скорости - сконцентрируйтесь на качестве и просто выполняйте их выборочно, если они слишком медленные. Ответы с конкретными номерами включали нацеливание на <10 мс до 0,5 и 1 секунду на тест или просто на то, чтобы весь набор обычно выполняемых тестов был менее 10 секунд.

Не уверен, правильно ли помечать один как «принятый ответ», когда они все полезны :)

13.08.2008 23:36:28
1 секунда на тест означает, что ваш набор тестов быстро достигнет точки, когда вы перестанете все время его запускать, потому что он кажется слишком медленным. Когда вы сможете запустить 100 тестов в секунду, вы будете запускать комплект гораздо чаще, чем когда это занимает в 100 раз больше времени.
Jeffrey Fredrick 9.01.2009 05:30:02
11 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

22
15.05.2018 01:45:25
Какой язык, компилятор и тестовый движок вы используете? 1000 тестов в секунду - это безумие. Мне трудно получить лучший результат, чем 4 теста в секунду в C # / Visual Studio 2010.
Nilzor 18.03.2011 08:23:15
Я подозреваю (не искал доказательств), что популярные бегуны-тестировщики в VS не прикладывают особых усилий для оптимизации своей скорости. 4 теста в секунду очень медленно. Если у вас будет большой набор тестов, вы хотите, чтобы его можно было обрабатывать сотнями в секунду. Выполнение их всех за секунду не является масштабируемым требованием для крупных проектов разработки.
Niall Connaughton 11.06.2013 01:17:16
Мы только что внесли небольшое изменение: тесты выполнялись в течение 6 минут вместо 2 часов. Теперь я вижу, что если бы тесты были быстрее, люди были бы более склонны работать над компонентом!
Tvde1 19.07.2019 10:08:33

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

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

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

1
13.08.2008 23:44:34

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

4
13.08.2008 23:44:35

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

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

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

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

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

1
13.08.2008 23:48:17

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

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

0
13.08.2008 23:54:16

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

0
16.03.2020 10:49:23

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

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

  • количество тестов: 3851 (приблизительно)
  • время выполнения: 9 мин, 6 сек
  • скорость выполнения: 7 тестов / сек
1
14.08.2008 05:59:27

Как долго это слишком долго для отдельного модульного теста?

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

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

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

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

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

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

0
24.11.2008 08:40:53

Цель - 100 тестов в секунду. Вы добьетесь этого, следуя правилам модульных тестов Майкла Фезера .

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

3
20.11.2008 17:05:38

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

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

0
24.11.2008 08:47:35

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

Как долго это слишком долго для отдельного модульного теста?

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

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

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

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

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

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

0
17.09.2011 08:33:06