Подтвердить что ты не робот

Тестируемая разработка с помощью ASP.NET MVC - с чего начать?

Я много читал о Test-Driven Development (TDD), и я нахожу принципы, очень убедительные, основанные на личном опыте.

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

Итак... Я создаю пустое решение в Visual Studio 2010, добавляю проект веб-сайта ASP.NET MVC и тестовый проект.

Я также добавляю библиотеку классов под названием "Домен", для моих объектов домена и тестовый проект для этого.

Теперь мне интересно, с чего начать. Должен ли я писать тест, прежде чем я все сделаю правильно? Вопрос в том, должен ли я начинать писать тесты для объектов домена? Если да, что именно я должен тестировать, поскольку объекты домена еще не существуют?

Или я должен начинать с проекта веб-сайта и писать тесты для этого? Если да, то зачем мне писать тест? Домашний контроллер/действие индекса?

4b9b3361

Ответ 1

Обычно я начинаю с сбора набора рассказов для приложения, которое я собираюсь разработать. Из этого я генерирую модель домена, обычно на "бумаге". Я организую рассказы, которые я собираюсь внедрить, и приступить к созданию модели домена в БД для первого набора рассказов.

Как только у меня есть начальная БД, я использую ORM, в моем случае, LINQ to SQL, чтобы сопоставить таблицы БД с набором начальных классов. Обычно я не создаю unit test сгенерированный код, поэтому это дает мне достаточное количество кода в качестве основы для начала. Затем я создаю метод заглушки, который генерирует исключение, которое не реализовано, для реализации одной функции первого класса домена, с которым я работаю. Как правило, я начинаю с логики проверки. После того, как у вас есть свой метод заглушки, вы можете использовать меню правой кнопки мыши для создания одного или нескольких модульных тестов для этого метода. Тогда вы в пути.

Как только я закончил с объектами домена для первого рассказа, я начал работать с аспектами MVC. Во-первых, я создам модели представления для первого представления. Как правило, это просто пустой контейнерный класс. Затем я создам представление и сильно наберу его на модель представления. Я начну формировать представление, добавляя свойства к модели представления по мере необходимости в представлении. Обратите внимание, что поскольку модель представления представляет собой просто контейнер, обычно нет связанных с ним модульных тестов. Однако он будет использоваться в последующих тестах контроллера.

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

Повторяйте по мере необходимости, пока не будет реализован ваш набор историй, рефакторинг по пути.

Ответ 2

Написание единиц тестирования перед тем, как объявить класс, который вы тестируете, кажется немного экстремальным в статических языках, таких как С#. Итак, вы начинаете с объявления классов домена, создавая несколько интерфейсов, которые определяют операции, которые вы будете выполнять на этих объектах домена, а затем добавляете класс, который будет реализовывать интерфейс, оставляя методы просто throw NotImplementedException. В этот момент вы можете написать unit test для этого класса, так как известны все типы. Вы запускаете тест, который потерпит неудачу, затем вы реализуете метод и снова запускаете тест - он пройдет. Затем вы можете реорганизовать и оптимизировать свою реализацию, ваш unit test должен все же проходить.

После того, как у вас есть хорошая модель домена и уровень доступа к данным, вы можете перейти к веб-проекту, где вы создаете контроллеры, используя ранее определенные интерфейсы (путем создания конструктора, который использует этот интерфейс). Вы пишете unit test для этого контроллера, заменив интерфейс макетным объектом, чтобы вы могли тестировать действия контроллера изолированно от вашего кода доступа к данным.

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

Ответ 3

Для долгого ответа вы должны сделать небольшие шаги, как это.

1) - Сначала напишите неудачный тест

    [Test]
    public void AddSameTag()
    {
        UserMovie userMovie = new UserMovie();

        userMovie.AddTag("action", "dts", "dts");
        Assert.AreEqual(2, userMovie.Tags.Count);
    }

2) - Напишите простейший код для прохождения теста.

public virtual void AddTag(params string[] tags)
    {
        foreach (var text in tags)
        {
            Tag tag =new Tag(text.Trim());
            if (!movieTags.Contains(tag))
                movieTags.Add(tag);
        }
    }

3) - Рефакторинг

. Для стартеров ASP.NET MVC и TDD вы можете игнорировать тест контроллера и сфокусироваться на домене TDD.