Как вы структурируете свои тесты NUnit для большого проекта?

Question

Мне интересно узнать, смогу ли я улучшить способ использования NUnit в решении Visual Studio, содержащем более 30 проектов.

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

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

Answer 1

Чтобы ответить на ваш первый вопрос:

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

Чтобы ответить на ваш второй:

Вы можете использовать категории и атрибуты [Explicit] и [Ignore], чтобы указать NUnit, какие тесты выполнять и какие тесты вы должны указать это бежать, прежде чем это будет. Вы также можете посмотреть [Platform] или некоторые другие атрибуты, в зависимости от того, какие именно требования предъявляются к «среде».

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

Answer 2

Для вашего случая я бы поставил несколько вариантов:

• Консолидация существующих проектов с меньшим количеством, следовательно, консолидация соответствующих тестовых проектов для них - Попробуйте подумать, действительно ли вам нужно 30 проектов (например, 30 сборок) или лучше просто объедините их, чтобы уменьшить количество зависимостей и время сборки.

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

• Объедините все модульные тесты в несколько проектов - Если вы непреклонны в отношении сохранения каждой сборки чистыми и раздельными, вы можете просто выбрать объединение всех модульных тестов, возможно, с точки зрения отношение друг к другу.

Следовательно, вы также можете создавать конфигурации решений, которые не включают в себя модульные тесты - если время сборки так вас беспокоит. Это особенно полезно, если вы просто запускаете тесты по требованию . Если вы используете непрерывную интеграцию, это не должно быть проблемой: у вас может быть несколько конфигураций CI, некоторые из которых включают в себя строительные тесты, другие - нет.

Answer 3

Это большой вопрос, который вызывает у меня некоторые опасения по поводу управления большим набором модульных тестов для длительных, больших проектов.

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

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

Answer 4

Кроме того, мы находим TestDriven.Net отличным внешним интерфейсом надстройки VisualStudio для NUnit, бесплатным для использования с открытым исходным кодом / учащимися.