как часто следует запускать весь набор модульных тестов системы?

Question

Как правило, я все еще являюсь неофитом юнит тестирования.

Кстати, вы также можете увидеть этот вопрос на других форумах, таких как xUnit.net, и так далее,
потому что это важный вопрос для меня. Я заранее прошу прощения за мой
кросс-постинг; ваше мнение очень важно для меня и не для всех
на этом форуме тоже относится к другим форумам.

Я смотрел на унаследованную большую десятилетнюю систему, которая прошла более 700 юнит-тестов
написано недавно (700 это только небольшое начало). Тесты написаны
в MSTest, но этот вопрос относится ко всем системам тестирования AFAIK.

Когда я запускал «Всех ИСПЫТАНИЙ» по версии 2008, окончательный счет составлял только семь тестов.
Это около 1% от общего числа тестов, которые были написаны на сегодняшний день.

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ: Исходный код ASP.NET MVC 2 RTM, включая его модульные тесты,
доступно на CodePlex; эти модульные тесты также написаны в MSTest
хотя Брэд Уилсон (не относящийся к делу факт) позже присоединился к команде ASP.NET MVC
как его старший программист. Все 2000 плюс тесты запускаются, а не только несколько.

ВОПРОС: учитывая, что AFAIK целью модульных тестов является выявление поломок
в ЮТ я прав, думая, что «лучшая практика» - всегда,
или хотя бы очень часто запускают все тесты?

обновлено 2010-05-22

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

imho, есть несколько лучших ответов на этот вопрос, но AFAIK SO позволяет я выбрал только один, поэтому, чтобы быть справедливым, я поставил галочку Пит Джонс за то, что был первым и получил наибольшее количество голосов от SO сообщества. Эско Луонтола из Финляндии также дал отличный ответ (надеюсь, он не похоронен в вулканическом пепле) и две очень хорошие ссылки, которые стоят вашего времени imho; определенно ссылка на F.I.R.S.T. для меня вдохновляет; AFAIK, только xUnit.net в мире .NET предлагает «любой заказ, в любое время». Вторая ссылка Эско - на действительно превосходное 92-минутное видео "Интеграционные тесты - афера" представленный Дж. Б. (Джо) Райнсбергером (http://jbrains.ca, где есть больше контента стоит моего времени). Кстати, блог Эско также стоит посетить http://orfjackal.net.

Answer 1

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

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

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

Answer 2

Должна быть возможность быстрого запуска модульных тестов, чтобы вы могли запускать их после каждого простого изменения. Как сказано в http://agileinaflash.blogspot.com/2009/02/first.html

Тесты должны быть быстрыми. Если вы не решаетесь запускать тесты после простого изменения в одну строку, ваши тесты слишком медленные. Сделайте тесты настолько быстрыми, что вам не придется их рассматривать. [...] Программный проект в конечном итоге будет иметь десятки тысяч модульных тестов, и члены команды должны запускать их все каждую минуту или около того без вины. Вы делаете математику.

Лично мой болевой порог составляет около 5-10 секунд; если для компиляции и запуска всех модульных тестов потребуется больше времени, это серьезно разозлит и замедлит меня.

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

Answer 3

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

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

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

Answer 4

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

Рекомендуется запускать модульные тесты как часть процесса ночной сборки.

Answer 5

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

Однако при большом количестве тестов это может занять значительное время, поэтому вам необходимо иметь возможность управлять этим.

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

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