Как медленно слишком медленно для модульных тестов?

Майкл Перо, в работе "Эффективно с устаревшим кодом", на страницах 13-14 упоминает:

A unit test, который занимает 1/10 второй для запуска - медленный unit test... Если [юнит-тесты] не работают быстро, они не являются модульными тестами.

Я понимаю, почему 1/10-я секунда слишком медленная, если у вас 30 000 тестов, так как это займет около часа. Однако, это означает, что 1/1 секунды лучше? Нет, не совсем (как это всего на 5 минут быстрее). Таким образом, жесткое правило, вероятно, не идеально.

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

Чтобы привести пример тестовых скоростей. Взгляните на несколько тайм-аутов MSTest unit test:

0.2637638 seconds
0.0589954
0.0272193
0.0209824
0.0199389
0.0088322
0.0033815
0.0028137
0.0027601
0.0008775
0.0008171
0.0007351
0.0007147
0.0005898
0.0004937
0.0004624
0.00045
0.0004397
0.0004385
0.0004376
0.0003329

Среднее значение для всех 21 из этих модульных тестов составляет 0.019785 секунд. Обратите внимание, что самый медленный тест связан с использованием Microsoft Moles для издевательства/изоляции файловой системы.

Итак, в этом примере, если мой пакет unit test вырастет до 10 000 тестов, для запуска может потребоваться более 3 минут.

Ответ 1

Я посмотрел на один такой проект, где количество модульных тестов заставило систему занять слишком много времени, чтобы проверить все. "Слишком долго" означает, что вы в основном не делали этого как часть своей обычной программы разработки.

Однако, они сделали, чтобы классифицировать модульные тесты на две части. Критические тесты и "все остальное".

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

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

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

Это было сделано с помощью TeamCity, поэтому, даже если один агент сборки был занят полным приложением unit test, другие агенты сборки все равно могли бы получить обычные коммиты и выполнять критические модульные тесты так часто, как это было необходимо.

Ответ 2

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

Я хочу знать, что эти проекты могут быть проверены всесторонне за считанные секунды.

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

Ответ 3

Во-первых, посмотрите мой комментарий к ответу Зака о разнице между тестами UNIT и INTEGRATION.

Затем используйте инструмент, такой как Might-Moose (Mighty-Moose был заброшен, но есть и другие инструменты), который запускает только те тесты, на которые влияет изменение вашего кода (вместо всей вашей библиотеки тестов) каждый раз, когда вы регистрируете файл.

Ответ 4

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

Правила не адаптируются к каждому домену/проблемному пространству.

Мы не можем "разделить" этот метод на более мелкие методы, которые мы могли бы unit test: это крошечный, но очень сложный метод (с использованием безумно огромных предварительно вычисленных таблиц, которые невозможно быстро создать заново на летать и т.д.).

У нас есть единичные тесты для этого метода. Это единичные тесты. Они выполняют секунды. Это хорошая вещь [TM].

Теперь, конечно, я не оспариваю, что вы используете библиотеки модульного тестирования, такие как JUnit, для вещей, которые не являются модульным тестированием: например, мы также используем JUnit для тестирования сложного многопоточного сценария. Эти не являются "unit test", но вы ставите, что JUnit все еще управляет днем:)

Ответ 5

Так что твой вопрос?:-) Я согласен, истинная метрика здесь заключается в том, как долго разработчики должны ждать полного запуска модульных тестов. Слишком долго, и они начнут обрезать углы перед тем, как совершить код. Я бы хотел, чтобы полная сборка фиксации заняла менее минуты или две, но это не всегда возможно. В моей работе сборка фиксации использовала 8 минут, и люди только начали работать с небольшими частями, прежде чем совершать, поэтому мы купили более мощные машины: -)

Ответ 6

Как долго слишком долго для разработчика ждать завершения набора unit test? Это действительно зависит от того, как долго разработчики будут рады ждать отзывов об их изменении. Я бы сказал, если вы начнете говорить минут, чем слишком медленно, и вам, вероятно, следует разбить набор тестов на отдельные тестовые проекты и запустить их отдельно.