Тестирование интеграции ASP.NET MVC приложений

Question

Я никогда раньше не тестировал приложения ASP.NET MVC3, хотя у меня большой опыт работы с NUnit / JUnit / etc.и TDD.У меня вопрос: , какие стратегии я могу использовать для тестирования приложений MVC?

Редактировать: В центре моего внимания прежде всего стратегии тестирования, а также, ссосредоточиться на интеграционном тестировании - тестировании того, что реальные пользователи пройдут, когда они нажмут на мое приложение.

Моя настройка ASP.NET MVC с ORM (NHibernate или Dapper, в зависимости от проекта).

Существует ли набор веб-тестов, аналогичный NUnit?Должен ли я написать один?Или я должен (как-то) попытаться разбить свое приложение на миллион маленьких не-веб-библиотек DLL и протестировать их в NUnit?(Возможно ли это даже с ActiveRecord / NHibernate в качестве слоя ORM?)

Что вы делаете для тестирования такого рода приложений?

Я посмотрел на подобные вопросы SO и почти ничего не нашел, кроме как «вот как проверить контроллер».

Answer 1

Существуют различные виды тестов: модульные, интеграционные, приемочные, ...

Если вы говорите о модульных тестах, ASP.NET MVC создан с учетом тестируемости.Есть много статей, иллюстрирующих эти концепции.Вот один пример .И еще один .И все же еще один .Если вы хотите, чтобы ваше приложение было модульно тестируемым, вам придется разработать его таким образом, чтобы между различными слоями была слабая связь.Так, например, вы будете абстрагировать весь доступ к данным за интерфейсами, которые будут использоваться контроллерами.Вы будете использовать инфраструктуру DI, которая будет передавать конкретную реализацию (NHibernate или любую другую) в контроллер, а в модульном тестировании вы сможете использовать фиктивную среду для заглушки уровня доступа к данным и протестировать этот контроллер в полной изоляции.*

Answer 2

Когда мы говорим об интеграционном тестировании для приложения ASP.NET MVC, необходимо учитывать два момента:

1. Пакет тестирования должен взаимодействовать с приложением так же, как пользователи используют веб-браузер
2. Комплект тестирования должен быть в состоянии изолировать (макетировать) другую часть веб-приложения во время сеанса тестирования.

Если это ваш случай, то вот мой получатель:

1. Разместите ваше веб-приложение с помощью IIS Express с помощью командной строки

   iisexpress.exe /path:[path] /port:[port] 
   

2. Используйте Selenium web driver для эмуляции активности браузера.

3. Использование SpecFlow для определения пользовательских сессий в gherkin язык
4. Использование Deleporter для макетирования компонентов веб-приложения во времяон работает

Я написал подробную статью об этом подходе.Существует также github repo с этим реализованным подходом.

Answer 3

Я думаю, это зависит от того, что вы хотите проверить.Если вы хотите выполнить тестирование из пользовательского интерфейса, вам необходимо использовать какой-либо драйвер для пользовательского интерфейса, например Selenium или Watin .

Если вы также используете Specflow вместе с одним из этих веб-драйверов вы могли бы написать спецификации, как, например, в ruby.

Я бы сам не стал тестировать пользовательский интерфейс, поскольку считаю, что пользовательский интерфейс сильно изменится.Я бы сосредоточил внимание на приеме через контроллеры в приложении MVC и оставлял контроллеры действительно маленькими с минимальным количеством логики в них.Я думаю, что контроллеры должны просто обеспечить некоторую базовую проверку входных данных и затем делегировать их вашему приложению.

Все это также зависит от того, насколько сложным является ваше приложение, главное простое правило должно быть простым:).

Answer 4

Если вы уже знакомы с Nunit / Junit и TDD, эти стратегии просто необходимо применить для модульного тестирования веб-приложения MVC.

Нет необходимости писать наборы веб-тестов и не нужно разбивать ваше приложение на «миллион» маленьких не-web-библиотек. При этом вам по-прежнему необходимо разработать приложение, чтобы оно было тестируемым.

Очень простой тест контроллера может выглядеть следующим образом. Обратите внимание, что мой пример использует Moq для хранилища / DI.

[Test]
public void Edit_Get_Should_Lookup_Contact_From_Repository_And_Return_Edit_View()
{
    // arrange
    var _repository = new Mock<IContactRepository>();

    var expectedContact = new Contact
    {
        First = "first",
        Last = "last",
        Email = "mail@test.com"
    };

    var mockContext = new Mock<ControllerContext>();
    _repository.Setup(x => x.GetById(It.IsAny<int>())).Returns(expectedContact);

    var controller = new ContactController(_repository.Object)
    {
        ControllerContext = mockContext.Object
    };

    // act
    var result = controller.Edit(1) as ViewResult;
    var resultData = (Contact)result.ViewData.Model;

    // assert
    Assert.AreEqual("Edit", result.ViewName);
    Assert.AreEqual(expectedContact.First, resultData.First);
    Assert.AreEqual(expectedContact.Last, resultData.Last);
    Assert.AreEqual(expectedContact.Email, resultData.Email);
}

[HttpGet]
public ActionResult Edit(int id)
{
    var contact = _repository.GetById(id);

    return View("Edit", contact);
}

Если вы хотите еще несколько примеров модульного тестирования / mvc, просмотрите пример приложения для ужина с ботаником: http://nerddinner.codeplex.com/