Как бороться с медленными юнит-тестами при выполнении TDD в большом проекте на c #

Question

Используя Visual Studio 2017 NUnit и инструмент для повышения точности тестирования, как поддерживать хорошую скорость модульного тестирования при выполнении TDD в больших проектах c # (5000+).Даже если каждый из этих тестов занимает всего 5 мс, это 25 секунд, что довольно медленно для цикла TDD.

Наши тесты не вызывают базу данных и не вызывают внешние веб-службы.Они только проверяют бизнес-логику.

Я обнаружил, что при использовании moq выполнение только Mock.Setup () занимает почти 1 мс.Так как у нас может быть несколько вызовов moq setups на тесты, это основной виновник наших медленных модульных тестов.

Есть ли способ ускорить скорость юнит-тестов?Есть ли какие-нибудь насмешливые библиотеки быстрее, чем moq?Или, может быть, другой тестовый бегун, который быстрее?

Answer 1

Подумайте об избавлении от большинства ваших тестов.

Хотя у меня нет большого опыта работы с юнит-тестированием и TDD, ограниченный опыт у меня до * 1006.* указывают на то, что большинство модульных тестов совершенно бесполезны.И есть опытные люди, которые поддерживают мое мнение, в качестве примера этой точки зрения, рассмотрим эти две статьи:

• https://rbcs -us.com / documents / Why-Most-Unit-Testing-is-Waste.pdf

• https://rbcs -us.com / documents / Segue.pdf

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

• https://medium.com/pacroy/why-most-unit-testing-is-waste-tests-dont-improve-quality-developers-do-47a8584f79ab

• https://techbeacon.com/1-unit-testing-best-practice-stop-doing-it

Обратите внимание, что аргумент не о тестированииВ общем, речь идет об обширных модульных тестах, а не об интеграции и тестировании на системном уровне.

Answer 2

Вы идете по неверному кроличьему целому: общее время всех ваших юнит-тестов все еще находится в очень разумном диапазоне!

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

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

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

Итак, ответ таков: у вас все хорошо, не волнуйтесь.

У нас более 5000 модульных тестов Java.На нашем самом быстром сервере сборки может потребоваться около 10 минут, чтобы сработать их все.Но это все еще хорошо.Бэкэнд-билд все еще возвращается через 20 минут и сообщает нам «сломан» или «все в порядке».Зачем?Поскольку сервер сборки включается только тогда, когда я решаю, что мой набор изменений завершен, и я отправляю его на сервер.

Если эти 25 секунд являются проблемой, то, поскольку вы запускаете все тесты слишком часто, потому что вы запускаете их вручную.Теперь: скорее потратьте энергию, придумывая умные способы, чтобы выполнять релевантные тесты только при эффективной работе над конкретными проблемами.(в Java с JUnit это просто: я щелкаю по текущему пакету и иду «запустить все тесты здесь»)