Как сгруппировать тесты в TestSuite используя C# + NUnit

инструменты visual studio
,
#1

Используя проект unit тестов с MsTest можно делать Ordered Test(List), вижуал студия предоставляет интерфейс в котором ты просто в нужной последовательности расставляешь тесты из списка, и далее это все можно запустить в jenkinse. Но используя Nunit не получается создать Ordered Test(List) , т.к я понял он работает только с MsTest и тесты помеченные атрибутами Nunit он просто не видит . В документации по Nunit атрибута для создания TestSuite нет, как например есть в TestNg.
Собственно стает вопрос как группировать тесты ? Может все таки есть атрибут в Nunit или пример как его реализовать, или может это все вообще не правильный подход и надо создавать как-то отдельные джобы в дженкинсе.

#2

Какова конечная цель группировки?
Последовательность тестов играет роль?

#3

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

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

#4

Можно попробовать использовать атрибут Category Category Attribute · nunit/docs Wiki · GitHub
для группировки тестов.

Также как вариант кастомная проперти Property Attribute · nunit/docs Wiki · GitHub

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

#5

да, как раз последовательность играет роль. Я забыл уточнить что пишу не unit test для покрытия кода, а функциональные через UI с использованием Selenium. Собственно по этому считаю что в данном случае можно разбить на небольшие группы и отказаться от концепции что зависимость тестов это плохо.

#6

Последовательность не должна играть роль даже в UI-ых тестах.
Пример есть 3 теста
Тест 1
Действие 1
Проверка 1
Тест 2
Действие 2
Проверка 2
Тест 3
Действие 3
Проверка 3

Вы прогнали тесты и у вас упал третий тест
Или вы просто хотите проверить третий тест
В случае зависимых тестов вам надо сделать
Действие 1
Проверка 1
Действие 2
Проверка 2
Действие 3
Проверка 3

В случае независимого теста
Действие 1
Действие 2
Действие 3
Проверка 3
А вполне возможно что есть и более быстрый способ попасть в точку Проверка 3

Лучше всего использовать так называемые предусловия в каждом тесте
Т.е.
Тест3
Тест находится в состоянии (2)
Действие 3
Проверка 3

Тест находится в состоянии (2) - это некая проверка , находится ли тест в нужном состоянии и если нет, то способ прийти в это состояние

Самый простой пример предусловий
If (page.Url != expectedUrl)
page.GoTOUrl(expectedUrl)

1 лайк
#7

Я бы ещё добавил, что предусловия по возможности делайте НЕ через UI.
Например, если Вам нужно проверить создание аккаунта и смену пароля для аккаунта, то лучше сделать 2 отдельных теста.
Первый будет создавать аккаунт, а второй менять пароль. Причем пароль можно менять не тому аккаунту, который создал первый тест, а создавать аккаунт отдельно. Например через базу данных или API. Или использовать уже существующий аккаунт.

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

1 лайк