Сколько вы тестируете свои контроллеры? - PullRequest
Новая
       23

Сколько вы тестируете свои контроллеры?

0 голосов
/ 12 сентября 2009

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

Как вы думаете, нужны ли спецификации контроллера?

С уважением

Ответы [ 3 ]

2 голосов
/ 12 сентября 2009

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

0 голосов
/ 18 сентября 2009

Как вы думаете, нужны ли спецификации контроллера?

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

Для интеграционного тестирования я использую Cucumber. Это позволяет протестировать полный стек и убедиться, что ваше приложение работает так, как вы хотите. Для бизнес-логики (толстые модели) я все еще использую RSpec.

0 голосов
/ 12 сентября 2009

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

Предположим, у нас есть контроллер, который идет 

    try {
        result = mode.doSomething();

        if  (result.count == 0 )
             message = "none found"
             redisplay criterion page
        else if (result.count == 1 ) 
             display detail page
        else 
             display list page
    } catch exception {
        message = "bad things happened, please try again"
        redisplay criterion page
    }

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

    code: go to page X
    test: did you go to page X?

Если разработчик делает неправильный выбор X, он тоже ошибается! Если юзабилити-тестирование пользовательского интерфейса показывает, что Y - лучшая страница для отображения, мы обновляем код и тест в тандеме. Тест действительно чего-нибудь достиг?

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

...