Как медленно, слишком медленно для юнит-тестов?

Question

Michael Feathers, в Эффективно работает с устаревшим кодом , на страницах 13-14 упоминается:

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

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

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

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

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 для проверки / изоляции файловой системы.

Таким образом, в этом примере, если мой набор модульных тестов увеличится до 10000 тестов, может занять более 3 минут.

Answer 1

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

Однако, то, что они сделали, это классифицировали модульные тесты на две части. Критические испытания и «все остальное».

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

Answer 5

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

Answer 6

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