Чи є тестування одиниць основною ціллю MVC Pattern?

Нещодавно в інтерв'ю одним із запитань було "Чому ми використовуємо MVC?" Я просто відповів, що це набагато ближче до того, як багато систем реального світу! Пояснив переваги, що стосуються ремонтопридатності, масштабованості тощо. Але вони не переконалися і, нарешті, сказали мені, що MVC використовується в основному, оскільки це "дозволяє легко перевірити блок".

Хоча я знаю, що їхня думка є достовірною точкою, я все ще сумніваюся, чи не є основною причиною тому, що (i) навіть якщо я вирішу не писати модульні тестові шкали, MVC є ймовірним вибором (ii) Багато систем GUI, де Unit Testcases немає слідкуйте за MVC.

Отже, питання: "Чи тестування блоку є основною ціллю MVC Pattern?"

EDIT: Я припускаю, що вони, можливо, згадують простість тестових розробок / написання тестів 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