Запустите модульные / интеграционные тесты с Lab Management

У нас есть полная среда Lab Management, в которой выполняются тесты с закодированным пользовательским интерфейсом в ночных сборках. Мы пытаемся добиться того, чтобы наши интеграционные тесты (обычный TestMethod() с подключениями SQL) выполнялись непосредственно перед всеми тестами Coded UI, чтобы убедиться, что наши сценарии db выполняются правильно и что нет новых изменений, вызывающих какие-либо проблемы.

До сих пор я нашел способ выполнять тесты удаленно через.testrunconfig. Проблема, с которой мы сталкиваемся при таком подходе, заключается в том, что невозможно выбрать тестовый контроллер, подключенный к командному проекту, поэтому я думаю, что он будет полезен только для запуска тестов на физических машинах вне Lab Management?

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

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

2 ответа

Я думаю, это было бы полезно только для запуска тестов на физических машинах вне Lab Management?

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

Как насчет этого подхода:

  1. Создайте заказанный тест, содержащий все ваши интеграционные тесты.
  2. Создайте новый тестовый набор "Интеграционные тесты" и автоматизируйте его с помощью упорядоченного теста. Таким образом, вам не нужно обслуживать сотни тестовых случаев. Вы также можете создать несколько упорядоченных тестов, если хотите сгруппировать интеграционные тесты, а затем создать "основной" упорядоченный тест, содержащий их. Таким образом будет легче анализировать результаты тестов, особенно если у вас много тестов.
  3. Пусть интеграционные тесты выполняются как часть вашей существующей ночной сборки.
  4. Создайте новое определение сборки, которое не запускает сборку, но использует последнюю успешную ночную сборку, и пусть ваши тесты CodedUI выполняются с использованием шаблона лабораторной сборки.

Таким образом, у вас будут разные тестовые прогоны для разных видов тестов.

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

Это не совсем идеально, я знаю... но таким образом вы могли бы легко достичь своей цели.

Я не уверен, есть ли альтернативное решение, но в проекте, над которым я сейчас работаю, у нас есть и наши тестовые сборки модулей, и интеграционные тесты, установленные в параметрах процесса (Process>Basic>AutomatedTest>TestAssembly) в нашей Nightly Build.
Это было достигнуто за счет небольшого изменения шаблона процесса сборки по умолчанию (а не лабораторного по умолчанию), как вы и предлагали (я думал, что это стандартно, но это было давно).

Другие вопросы по тегам