mspec & rhino проверяет ожидаемое тестирование исключения - PullRequest
Новая
       24

mspec & rhino проверяет ожидаемое тестирование исключения

1 голос
/ 13 апреля 2011

Я довольно новичок в модульном тестировании и не могу понять, как правильно (или даже должен ли я) проверить этот случай.

У меня есть метод контроллера (псевдокод): 

public ActionResult Register(formModel model)
{

    if (ModelState.isValid) {

        try {

            _userService.CreateUser(a bunch of parameters here);
            return RedirectToAction(some other action);
        }
        catch (Exception e)
        {

            ModelState.AddModelError("",e.Message);

        }

    }

    return View();
}

У меня есть несколько отдельных тестов для "_userService".Метод «CreateUser» просто создает нового пользователя и ничего не возвращает, ИЛИ выдает исключение, если произошла ошибка (например, существует пользователь), которая всплывает до окружения контроллера при попытке try и добавляет исключение в ModelState.

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

Я не уверен, как проверить, что, когда userservice выдает ошибку, он не должен перенаправлять и должен добавить это исключение в состояние модели.С насмешками на носорога вы можете заглушить имитацию, но книга искусства модульного тестирования советует против этого.

Прямо сейчас в моем тесте я вручную добавляю ошибку модели (не обращая внимания, если это из пользовательского сервиса) и проверяю, что контроллервозвращает тот же вид, если есть ошибки.Это правильный способ сделать это?Или мне следует создать отдельный тест, в котором я заглушаю _userService, чтобы выдать ошибку и проверить, будет ли она добавлена ​​в состояние модели?Или мне даже не проверять этот случай?Я чувствую, что, может быть, я просто перебираю все это, и для этого достаточно тестирования с использованием состояния модели ...

1 Ответ

1 голос
/ 14 апреля 2011

Ваш макет представляет собой сотрудничающий класс. Я не стал бы слишком зацикливаться на разнице между издевательствами и окурками; это все еще сотрудничающий класс.

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

Given a controller
When I register the model
Then the class should ask the user service to create a user.

И 

Given a controller
Given the user service is broken
When I register the model
Then the class should attach the error to the model state.

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

Если вы поместите эти строки как комментарии в свой тест, это будет иметь смысл. Если это имеет смысл, игнорируйте книгу.

Кстати, это BDD на уровне единиц. Вы можете использовать «Дано, Когда, Тогда» на уровне блока, как и на уровне сценария, и это может помочь вам подумать о логике ваших тестов. Только не используйте инструменты сценария BDD для этого.

...