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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

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

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