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

Question

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

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

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

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

---

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

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

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

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

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

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

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

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

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

Answer 8

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

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

Answer 9

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

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

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

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

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

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

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

Answer 10

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