Является ли модульное тестирование основной целью MVC Pattern?

Недавно в интервью один из вопросов был «Почему мы используем MVC?» Я только что ответил, что это намного ближе к тому, как много систем реального мира! Объяснил преимущества, которые он имеет, когда дело доходит до обслуживания, масштабируемости и т. Д. Но они не были убеждены и, наконец, сказали мне, что MVC используется в основном, поскольку он «позволяет легко выполнять модульное тестирование».

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

Итак, вопрос «Является ли модульное тестирование основной целью MVC Pattern?»

РЕДАКТИРОВАТЬ: я предполагаю, что они могли бы упомянуть простоту разработки на основе тестирования / написания тестовых случаев NUnit. Это потому, что мы можем написать тестовые случаи для модели (при условии, что представление точно отражает изменения состояния модели) - пожалуйста, исправьте меня, если я ошибаюсь.

Основной целью было бы «разделение интересов», поскольку модель, представление и контроллер имеют разные обязанности.

Автор оригинала Xerox PARC бумаги говорится , что:

Основной целью MVC является преодоление разрыва между ментальной моделью пользователя и цифровой моделью, которая существует в компьютере.

Если бы модульное тестирование было основной целью, можно было бы легко выполнить модульное тестирование представлений. Взгляд на ландшафт проектов / структур модульного тестирования показал бы, что это совершенно противоречит заявленному заявлению. Как правило, можно использовать интеграционные и функциональные тесты для проверки представления.

На мой взгляд, ответом фирмы является «нет». Возможно, это было основным преимуществом, которое наблюдалось в этой конкретной организации, но я бы не назвал это «основной целью».

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

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

MVC (так же, как и большинство известных шаблонов проектирования) существовал еще до того, как стало известно о модульном тестировании. Книга GoF была опубликована в 1994 году - и они только документировали образцы, которые использовались в течение многих лет (если не десятилетий) прежде. (И в нем нет упоминания о модульном тестировании.) Что касается модульного тестирования, я не могу определить точное время, когда оно стало «общедоступным» - я лично читал об этом в статьях, связанных с экстремальным программированием, и в первой книге по XP вышел в 1999 году.

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

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

В мире ASP.NET MVC многие улучшения ASP.NET были включены в сам фреймворк. Основная цель этого шаблона проектирования состоит в том, чтобы изолировать бизнес-логику от пользовательского интерфейса, чтобы сосредоточиться на улучшении удобства сопровождения, улучшенной тестируемости и более четкой структуре приложения.

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

• Высокий уровень контроля над сгенерированным HTML : в отличие от веб-форм, представления в ASP.NET MVC отображают HTML точно так, как вы им говорите. В последнее время веб-формы были улучшены в этой области, но все еще не имеют уровня контроля, который имеет MVC.

• Более простое модульное тестирование : с ASP.NET MVC очень легко следовать шаблонам тестирования, таким как разработка через тестирование (TDD). Из-за сложного жизненного цикла событий в веб-формах, в дополнение к основанной на элементах управления среде, TDD намного проще с MVC.

• Разделение интересов : это означает, что все аспекты системы четко отделены друг от друга. Из-за шаблона, который он реализует, приложение MVC разделено на дискретные и слабо связанные части (модель, представления и контроллеры), что упрощает обслуживание.

Некоторые из других преимуществ:

• Сам шаблон MVC упрощает управление сложностью, четко разделяя функциональные возможности приложения на три основные части: модель, представление и контроллер.

• Веб-приложения ASP.NET MVC не используют состояние просмотра или формы на основе сервера. Это делает инфраструктуру MVC идеальной для разработчиков, которым нужен полный контроль над поведением приложения. Состояние просмотра может стать очень большим, что является проблемой для таких устройств, как смартфоны, работающие в медленных сетях (передача всей этой информации может быть очень медленной). На странице веб-форм вы можете иметь только одну на страницу. Это довольно серьезное ограничение. В MVC такого ограничения нет, то есть вы можете иметь столько элементов, сколько захотите.

• ASP.NET MVC обеспечивает улучшенную поддержку разработки через тестирование (TDD).

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