Контроллеры модульного тестирования ASP.NET MVC - хранилища - PullRequest
Новая
       34

Контроллеры модульного тестирования ASP.NET MVC - хранилища

2 голосов
/ 27 мая 2010

Это скорее вопрос для выяснения мнения, поэтому, возможно, не будет «правильного» ответа, но я бы приветствовал аргументы относительно того, почему ваш ответ «правильный».

Учитывая приложение MVC, которое использует Entity Framework для механизма сохраняемости, уровень хранилища, уровень обслуживания, который в основном относится к хранилищу, и метод удаления на контроллере, который выглядит следующим образом: 

    public ActionResult Delete(State model)
    {
        try
        {
            if( model == null )
            {
                return View( model );
            }

            _stateService.Delete( model );

            return RedirectToAction("Index");
        }
        catch
        {
            return View( model );
        }
    }

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

    [TestMethod]
    public void Delete_Post_Passes_With_State_4()
    {
        //Arrange
        var stateService = GetService();
        var stateController = new StateController( stateService );

        ViewResult result = stateController.Delete( 4 ) as ViewResult;
        var model = (State)result.ViewData.Model;

        //Act
        RedirectToRouteResult redirectResult = stateController.Delete( model ) as RedirectToRouteResult;

        stateController = new StateController( stateService );

        var newresult = stateController.Delete( 4 ) as ViewResult;
        var newmodel = (State)newresult.ViewData.Model;

        //Assert
        Assert.AreEqual( redirectResult.RouteValues["action"], "Index" );
        Assert.IsNull( newmodel );
    }

Это перебор? Нужно ли проверять, действительно ли удалена запись (так как у меня уже есть тесты Service и Repository, которые это подтверждают)? Должен ли я даже использовать здесь поддельный репозиторий или было бы логичнее просто издеваться над всем этим?

В примерах, которые я смотрю, использовалась эта модель ведения дел, и я просто скопировал ее, но я действительно открыт для того, чтобы делать что-то «наилучшим образом».

Спасибо.

Ответы [ 2 ]

2 голосов
/ 27 мая 2010

Я лично в такой ситуации использовал бы поддельный сервис.

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

Что касается других ваших тестов, я бы использовал Fake Repository для тестирования сервисного уровня. Что касается тестирования репозитория, у меня была бы тестовая настройка базы данных, чтобы протестировать все методы и убедиться, что есть способ вернуть базу данных к ее первоначальной настройке, поэтому каждый раз, когда вы запускаете тестирование, вы проверяете те же данные. *

0 голосов
/ 11 июня 2010

Я согласен, что если вы тестировали другие слои и т. Д. В других местах, вам не нужно тестировать контроллер.

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

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

Опять же, вы не тестируете базу данных. Вы тестируете свой контроллер.

...