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

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

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

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

20.08.2008 19:07:51
7 ОТВЕТОВ
РЕШЕНИЕ

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

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

18
26.09.2009 16:58:04
ну, может быть, Selenium - это проблема для одних ... но именно поэтому у других есть работа :)
kiedysktos 13.07.2015 12:45:43

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

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

4
20.08.2008 19:16:02

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

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

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

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

2
20.08.2008 19:19:53

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

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

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

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

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

2
14.11.2012 15:37:46

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

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

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

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

0
29.09.2008 18:12:06

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

0
21.10.2008 20:40:43

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

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

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

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

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

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

2
26.09.2009 17:23:21