Установить NUnit

Идем по ссылке https://sourceforge.net/projects/nunit/ и устанавливаем NUnit. Так же в VS устанавливаем NUnit Test Adapter (ну чтобы запускать тесты прямо в VS).

Создадим папочку типа Solution Folder Test и в нее добавим проект LessonProject.UnitTest и установим там NUnit:

Install-Package NUnit

Создадим класс UserControllerTest в (/Test/Default/UserContoller.cs):

[TestFixture]

public class UserControllerTest

{

}

Итак, принцип написания наименования методов тестов Method_Scenario_ExpectedBehavior:

· Method – метод [или свойство], который тестируем

· Scenario – сценарий, который мы тестируем

· ExpectedBehavior – ожидаемое поведение

Например, проверяем первое, что возвращаем View c классом UserView для регистрации:

public void Register_GetView_ItsOkViewModelIsUserView()

{

Console.WriteLine(" =====INIT======");

var controller = new UserController();

Console.WriteLine(" ======ACT======");

var result = controller.Register();

Console.WriteLine(" ====ASSERT=====");

Assert.IsInstanceOf< ViewResult> (result);

Assert.IsInstanceOf< UserView> (((ViewResult)result).Model);

}

Итак, все тесты делятся на 3 части Init-> Act-> Assert:

· Init – инициализация, мы получаем наш UserController

· Act – действие, мы запускаем наш controller.Register

· Assert – проверка, что всё действительно так.

Откроем вкладку Test Explorer:

Если адаптер NUnit правильно был установлен, то мы увидим наш тест-метод.

Запускаем. Тест пройден, можно идти открывать шампанское. Стоооп. Это лишь самая легкая часть, а как быть с той частью, где мы что-то сохраняем. В данном случае мы не имеем БД, наш Repositary – null, ноль, ничего.

Изучим теперь класс и методы для инициализации (документация):

· SetUpFixture – класс, помеченный этим атрибутом, означает, что в нем есть методы, которые проводят инициализацию перед тестами и зачистку после тестов. Это относится к одному и тому же пространству имен.

o Setup – метод, помеченный этим атрибутом, вызывается до выполнения всех тестовых методов. Если находится в классе с атрибутом TestFixture, то вызывается перед выполнением методов только этого класса.

o TearDown – метод, помеченный этим атрибутом, вызывается после выполнения всех тестов. Если находится в классе с атрибутом TestFixture, то вызывается после выполнения всех методов.

Создадим класс UnitTestSetupFixture.cs (/Setup/UnitTestSetupFixture.cs):

[SetUpFixture]

public class UnitTestSetupFixture

{

[SetUp]

public void Setup()

{

Console.WriteLine(" ===============");

Console.WriteLine(" =====START=====");

Console.WriteLine(" ===============");

}

[TearDown]

public void TearDown()

{

Console.WriteLine(" ===============");

Console.WriteLine(" =====BYE! ======");

Console.WriteLine(" ===============");

}

}

Запустим и получим:

===============

=====START=====

===============

=====INIT======

======ACT======

====ASSERT=====

===============

=====BYE! ======

===============

Mock

Итак, Mock – это объект-пародия. Т.е. например, не база данных, а что-то похожее на базу данных. Мираж, в общем-то. Есть еще Stub – это заглушка. Пример метода заглушки:

public int GetRandom()

{

return 4;

}

Но мы будем использовать Mock:

Install-Package Moq

Определим, какое окружение есть у нас, чтобы мы проинициализировали для него Mock-объекты. В принципе, это всё, что мы некогда вынесли в Ninject Kernel:

· IRepository

· IConfig

· IMapper

· IAuthentication

И тут я сделаю небольшое замечание. Мы не можем вынести Config в объекты-миражи. Не в плане, что это совсем невозможно, а в плане – что это плохая затея. Например, мы изменили шаблон письма так, что string.Format() выдает ошибку FormatException. А в тесте всё хорошо, тест отлично проходит. И за что он после этого отвечает? Ни за что. Так что файл конфигурации надо использовать оригинальный. Оставим это на потом.

По поводу, IMapper – в этом нет необходимости, мы совершенно спокойно можем использовать и CommonMapper.

Но для начала проинициазируем IKernel для работы в тестовом режиме. В App_Start/NinjectWebCommon.cs мы в методе RegisterServices указываем, как должны быть реализованы интерфейсы, и вызываем это в bootstrapper.Initialize(CreateKernel). В дальнейшем мы обращаемся по поводу получения сервиса через DependencyResolver.GetService(). Так что создадим NinjectDependencyResolver (/Tools/NinjectDependencyResolver.cs):

public class NinjectDependencyResolver: IDependencyResolver

{

private readonly IKernel _kernel;

public NinjectDependencyResolver(IKernel kernel)

{

_kernel = kernel;

}

public object GetService(Type serviceType)

{

return _kernel.TryGet(serviceType);

}

public IEnumerable< object> GetServices(Type serviceType)

{

try

{

return _kernel.GetAll(serviceType);

}

catch (Exception)

{

return new List< object> ();

}

}

}

Добавим в SetUp метод (/Setup/UnitTestSetupFixture.cs):

[SetUp]

public virtual void Setup()

{

InitKernel();

}

protected virtual IKernel InitKernel()

{

var kernel = new StandardKernel();

DependencyResolver.SetResolver(new NinjectDependencyResolver(kernel));