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

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

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

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

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

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

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

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

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

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

Если вы не очень хорошо относитесь к написанию тестов, вы, вероятно, делаете это неправильно ;)

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

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

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

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

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

Ваш кодовый поиск будет, следуя этому шаблону, делать две вещи:

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

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

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

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

Были попытки заставить Microsoft free UI Automation (included in .NET Framework 3.0) работать с веб-приложениями (ASP.NET). Немецкая компания под названием Artiso случайно написала запись в блоге, которая объясняет, как этого достичь ( ссылка).

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

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

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