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

1

Я работаю с Unit Test с помощью VS2013 Professional. В частности, я использую структуру NUnit (NUnit TestAdapter для VS2013). Моя проблема в том, что когда я запускаю свои тесты, тогда VS начинает строить все проекты внутри решения. В настоящее время проект Unit Test не ссылается ни на один проект решения.

Если я просто закодирую один метод тестирования, например:

[Test]
public void SimpleTestMethod(){
    Assert.That("a", Is.EqualTo("a"));
}

и проект Unit Test находится в проекте Solution with N, когда я запускаю свой тест, тогда VS построит весь проект N-1... В моем случае это поведение скучно, потому что требуется слишком много времени (решение содержит много проектов) и некоторые проекты содержат ошибки.

Есть ли способ запустить мой SimpleTestMethod() без полного построения решения?

  • 1
    Если проект ссылается на несколько измененных проектов, он всегда будет перестраивать его. Это необходимо, так как он не знает, будет ли что-нибудь сломаться, пока сборка не будет завершена.
Теги:
unit-testing
visual-studio-2013
nunit

2 ответа

2
Лучший ответ

Разбейте тестовый проект на несколько проектов, которые ссылаются только на подмножество проектов решений.

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

  • Тесты выполняются быстрее
  • Гораздо проще изолировать тестовые примеры, особенно настройки конфигурации
  • Вы можете проектировать проекты и их тестовые примеры вместе

Хорошая практика именования - назвать ваши тестовые проекты такими же, как и их целевые проекты, с суффиксом .Tests. Вы также можете создать папку решений (не настоящую папку) под названием "Тесты" и переместить в нее тестовые проекты.

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

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

Есть несколько вариантов остановки, которые вы можете использовать, пока не сможете исправить ошибку:

  • Временно удалите сломанный проект из конфигурации сборки
  • Разделите решение так, чтобы у вас было решение, которое можно было бы построить и протестировать
Поделиться
  • 0
    Я уверен, что это хороший совет, но в данный момент мой тестовый проект не ссылается ни на какой другой проект решения. Я только что добавил тестовый проект в решение и написал SimpleTestMethod ().
  • 0
    @baru Это противоположно тому, что вы пишете в вопросе ( any references to any solution project is referenced to the Unit Test project ). В любом случае, тестовые прогоны - это внешние инструменты, предназначенные для артефактов сборки (т. Е. Скомпилированных сборок). Сломанная сборка = нет сборочных артефактов
Показать ещё 2 комментария
0

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

Я начал выполнять тесты через командную строку. Процесс сборки не требуется. Вы можете написать свои собственные.bat файлы и вести журналы результатов тестирования. Существует множество параметров командной строки, которые можно добавить для настройки того, что вы ищете.

https://msdn.microsoft.com/en-us/library/jj155796.aspx

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню