Лучший макет фреймворка, который может работать как с WebForms, так и с MVC?

Я больше вхожу в рабочий процесс TDD и использую смесь приложений MVC и asp.net Web Forms.

MOQ рекомендуется для MVC.

Я использовал Rhino для веб-форм.

У кого-нибудь есть лучшая практика для создания 1 фреймворка для обоих?

Ответов (5)

Решение

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

TL; DR: MoQ это детка.

Посмотрите на Ivonna на предмет подделки HTTPContext и традиционных веб-форм.

http://sm-art.biz/Ivonna.aspx

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

Мой любимый - Moq. Я также использовал TypeMock. Это стоит денег, но это действительно мощно - оно позволяет имитировать конкретные классы и конструкторы, так что вы потенциально можете имитировать такие вещи, как HttpContext или HttpRequest.

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

Но когда я нахожу время, чтобы выбрать архитектурный шаблон (MVC) или разработать тот, который позволяет использовать Mockability (вы знаете, публичные методы изменения состояния виртуализации), я использую Moq. Это так просто использовать и так просто учить других.

Синтаксис воспроизведения записей TypeMock все еще сбивает меня с толку, но он сэкономил мне много времени в плотном графике выпуска. API Moq почти не требует пояснений, что является удивительным достижением, учитывая историю фиктивной библиотеки.

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

Внимательно изучите TypeMock, прежде чем переходить к цене.

Кроме того, для ASP.NET MVC не существует рекомендуемой среды фиксации.

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