Как написать Варианты использования и Разработка на основе тестирования для привязки gridview Пример

Question

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

Вот мой псевдо подход:

1. Создайте страницу aspx и добавьте к ней элемент управления gridview.
2. создайте метод в коде с именем BindGrid (datacollection, gridview), который передает коллекцию и gridview методу в классе за пределами моего веб-сайта, поэтомуЯ действительно могу написать модульный тест для метода и вернуть сетку с привязкой к данным.
3. В методе BindGrid я щелкаю правой кнопкой мыши и выбираю «Создать модульный тест», который создает для меня новый тестовый проект с контурным тестом.для моего метода BindGrid ().
4. Теперь я предполагаю, что можно написать ряд тестов, например: testTrueDataCollectionBindstoGridView (), чтобы увидеть, действительно ли тип данных коллекции связывается?Я не уверен, что написать другой тест?

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

Спасибо

Обновление:

У меня естьрешил попытаться упростить мой вопрос в надежде получить больше идей.

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

Спасибо

Answer 1

В некоторой степени ваш вопрос описывает, почему были созданы платформы ASP.NET MVC.Очень сложно написать тесты для модели ASP.NET Web Forms (частью которой является GridView).Кроме того, вы, похоже, близки к написанию тестов для тестирования самой платформы, а не кода, который вы пишете.Если вы зайдете слишком далеко по этому пути, вы будете писать тесты вечно и никогда не выпускаете никакого кода.В этом случае было бы более продуктивным отделить любой код, который вы использовали для генерации коллекции, которую вы привязываете к GridView, и тщательно протестировать сценарии вокруг ее создания (и особенно любые условия исключений и возможную условную логику) и веритьFramework привязывает данные к сетке правильно.Если метод генерации данных может генерировать какие-либо исключения, которые вы хотите обработать на уровне пользовательского интерфейса, попробуйте проверить, как ваш код обрабатывает это, но опять же, именно здесь полезны фреймворки MVC, т.к. очень трудно тестировать кодкоторый должен быть запущен в течение жизненного цикла веб-форм.

Answer 2

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

Я бы порекомендовал, для целей изучения TDD не писатьтесты поведения UI (например, привязка данных к элементу управления).

Чтобы эффективно изучить TDD, я думаю, что хорошее место для начала - попробовать несколько кодовых катов.Код ката - это небольшая проблема, которую вы делаете неоднократно.Решение, которое вы разрабатываете, не главное - учитесь на процессе получения решения.Так что делайте задачу 10 раз, и каждый раз сознательно выбирайте разные варианты решения.TDD о процессе.

Здесь есть список кат: http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue

Ката с римскими цифрами - хорошая, но просто выберите ту, которая вам нравится.

Answer 3

Просто в общих чертах, так как в настоящее время я в основном занимаюсь Java, а не .NET. Я считаю, что TDD сначала кажется довольно неуклюжим для большинства людей, но дайте ему немного времени и посмотрите, нравится вам это или нет.

Что касается написания тестов, используйте этот общий подход. Создайте метод, который вы хотите протестировать, но без какого-либо тела. Создайте тест, выполняющий определенное поведение, и сделайте его простым Запустите тест, и он должен провалиться (запустите красный, если ваша IDE делает это). Затем напишите строку или пару строк кода, которые позволят успешно выполнить тест (выделите зеленым цветом). Теперь напишите еще один тест и повторите. Если у вас есть условия, убедитесь, что все пути проверены. То есть, напишите один путь, затем другой, написав тест для каждого первого.

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

Убедитесь, что вы часто запускаете тесты во время рефакторинга.