Что из следующего является лучшим способом написания модульного теста и продолжения работы с TDD в ASP.NET MVC

Question

Прочитав некоторое время о MVC и Test Driven Development, я только начинаю преобразовывать свое веб-приложение в MVC.Я использую эту книгу в качестве одной из ссылок для изучения TDD в ASP.NET MVC.

Юнит-тест из этой книги выглядит следующим образом:

[TestMethod()]
public void Register_Can_Get_To_View()
{
    var target = new AccountController();
    var results = target.Register();
    Assert.IsNotNull(results);
    Assert.IsInstanceOfType(results, typeof(ViewResult));
    Assert.AreEqual("Register", target.ViewData["Title"]);
}

Я также смотрю на исходный код nerddinner из codeplex, и там аналогичный Юнит-тест пишется следующим образом

[TestMethod]
public void Index() 
{
    // Arrange
    HomeController controller = new HomeController();

    // Act
    ViewResult result = controller.Index() as ViewResult;

    // Assert
    Assert.IsNotNull(result);
}

В первом случае автор сравнивает тип результатов с ViewResult.Однако во втором случае результат преобразуется как ViewResult, а это не проверяется.

Что лучше, и нужно ли мне действительно подробно тестировать, как показано в первом случае?

Answer 1

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

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

Идея:

1. Напишите тест, который не компилируется.
2. Напишите достаточно для компиляции, но все равно не получится (т. Е. NotImplementedException).
3. Напишите достаточно , чтобы пройти тест (вы можете жестко закодировать тестируемый модуль, чтобы пройти тест).
4. Напишите еще один тест, который не удался (что заставляет вас использовать лучшую реализацию, чем жесткое кодирование, для учета другого ввода).
5. Внесите изменения, чтобы тест снова прошел.
6. Повторять до тех пор, пока устройство не будет полностью протестировано (т.е. все возможные / подходящие входы учтены, а неподходящие входы проверены и отклонены соответствующим образом).

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

В этом случае я бы посоветовал заявить следующее:

• Чтобы результат действия контроллера не был нулевым.
• что свойство Model имело правильный тип (при условии строго типизированных представлений).
• Чтобы каждое свойство в Model или каждое значение в ViewData было правильным значением для данного ввода.

Answer 2

Первый тест выглядит так, как будто действие контроллера использует ViewData вместо просмотра моделей. Для меня это плохо. Он использует магические струны и он чрезвычайно хрупок. Поэтому больше не нужно комментировать это.

Второй тест не делает ничего полезного, кроме проверки того, что действие контроллера вернуло представление.

Но более действительное действие контроллера передаст модель представления этому представлению. Так что вам нужно проверить это. Лично я предпочитаю MVCContrib TestHelper , поскольку это делает мои модульные тесты очень беглыми и удобочитаемыми:

[TestMethod]
public void Index() 
{
    // Arrange
    var controller = new HomeController();

    // Act
    var actual = controller.Index();

    // Assert
    actual
        .AssertViewRendered()
        .WithViewData<MyViewModel>()
        .ShouldNotBeNull("the view model was null");
}

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