Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Правильное использование NUnit


(Павел Смолкин) #1

Привет!
В связи с отсутствием достаточного опыта, периодически возникают разные вопросы, не имеющие очевидного мне ответа.
Вот сейчас задумался о правильности использования asserts в NUnit.
Представьте себе один небольшой, но очень гипотетически гордый фреймворк для функционального тестирования с помощью WebDriver и NUnit. Идея изначально была в том, чтобы завернуть все проверки подальше и поглубже от того, кто собственно будет создавать тест-кейсы (предполагая его невысокую квалификацию, например).
Так вот, насколько это будет плохой или хорошей практикой вместо Assert вызывать собственные исключения, генерируемые при автоматических проверках внутри фреймворка.
То есть чтоб тест выглядел примерно так:

MainPage.OpenPage().SetData(data).CalculateClick().HomeClick();

а не так

MainPage page = MainPage.OpenPage();
page.SetData(data);
Assert........;
Assert........;
Assert........;
page.CalculateClick()
Assert........;
Assert........;
Assert........;
page.HomeClick();
Assert........;

Такая мысль возникла в том числе потому, что в тестируемом проекте очень много зависимых друг от друга элементов (активность элементов, загрузка справочников в зависимости от предыдущего выбора и т.п.). То есть, мне видится, что описать логику страницы лучше один раз, чем делать это потом многократно.
Но раз так никто не делает, то логичный возникает вопрос: что не так в моем понимании вопроса?


(Sergey Korol) #2

Без привязки к NUnit скажу, что оба приведенных примера концептуально неверны. Объясняю почему:

  • В первом случае вы сокрываете ассерты внутри page логики, что само по себе является моветоном. Проверки не должны быть частью логики страницы.
  • Второй пример показывает то, что вы пытаетесь в одном тесте проделать как можно больше проверок чуть ли не на каждом степе. Если, к примеру, это не мягкие ассерты, то вы никогда не узнаете результат следующей проверки в случае фейла предыдущей. Но даже если вы припилили soft asserts, какой смысл перегружать тест проверками косвенной функциональности?

Сама идея оборачивания проверок в какой-то удобоваримый язык - неплохая. Но реализация должна быть явно другой. Пусть это будет отдельный модуль, из которого вы сможете дергать ваши проверки aka generic verifications. Ну или посмотрите в сторону готовых решений. К примеру, в Java есть библиотека AssertJ, которая предоставляет свою собственную обертку для удобства формирования проверок. Возможно, нечто подобное есть и в .Net.