Лучшая практика интеграции TDD с разработкой веб-приложений?

Question

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

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

Как вы или ваша организация интегрируете лучшие практики TDD с разработкой веб-приложений?

Answer 1

Модульное тестирование будет достижимо, если вы разделите ваши слои соответствующим образом.Как подразумевал Роб Купер, не добавляйте в свою веб-форму никакой логики, кроме логики управления презентацией.Все остальные уровни логики и персистентности должны храниться в отдельных классах, и затем вы можете протестировать их по отдельности.

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

Answer 2

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

Я рассматривал FitNesse, Watin и Selenium как варианты автоматизации тестирования пользовательского интерфейса, но у меня пока не было времени использовать их ни в каких проектах, поэтому мы придерживаемся тестирования на людях.Фитнесс был тем, к чему я склонялся, но я не мог представить это так же хорошо, как представить TDD (разве это делает меня плохим?Надеюсь, что нет!).

Answer 3

Это хороший вопрос, на который я тоже подпишусь :)

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

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

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

Answer 4

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

Попробуйте запустить набор тестов до того, как написание строки фактического кода в новом проекте, поскольку позже будет сложнее писать тесты.

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

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

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

Если вам не нравится писать тесты, вы, вероятно, делаете это неправильно ;)

Answer 5

Обычной практикой является перемещение всего кода, который вы можете, из codebehind в объект, который вы можете тестировать изолированно.Такой код обычно следует шаблонам проектирования MVP или MVC.Если вы выполните поиск по "Rhino Igloo", вы, вероятно, найдете ссылку на его репозиторий Subversion.Этот код стоит изучить, поскольку он демонстрирует одну из лучших реализаций MVP для веб-форм, которые я видел.

Следуя этому шаблону, ваш codebehind выполнит две вещи:

1. Передайте все действия пользователя ведущему.
2. Визуализируйте данные, предоставленные ведущим.

Модульное тестирование презентатора должно быть тривиальным.

Обновить:Иглу Носорога можно найти здесь: https://svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-igloo/

Answer 6

Предпринимались попытки заставить бесплатную программу Microsoft для автоматизации пользовательского интерфейса (входит в .NET Framework 3.0) работать с веб-приложениями (ASP.NET).Немецкая компания под названием Artiso случайно написала запись в блоге, в которой объясняется, как этого добиться (Ссылка).

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

Я спросил об этом Томаса Шисслера (Artiso), и он объяснил, что это главный недостаток InternetExplorer.Он сослался на более старую технологию Microsoft (MSAA) и сам надеялся, что IE8 сделает это лучше.

Тем не менее, я также попробовал Watin, и, кажется, это работает довольно хорошо.Мне даже понравился Wax, который позволяет реализовывать простые тестовые наборы с помощью таблиц Microsoft Excel.

Answer 7

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