Чому тестується MVC Views?

Наразі я встановлюю основу для програми ASP.Net MVC, і я розглядаю, які саме тестові одиниці я повинен бути готовий написати. Я бачив, що люди в багатьох місцях говорять: "Не турбуйтеся перевіряти свої погляди, немає логіки, і це банально, і тест на інтеграцію буде охоплений".

Я не розумію, як це стало прийнятою мудрістю. Інтеграційні тести служать зовсім іншому призначенню, ніж одиничні тести. Якщо я щось зламаю, я не хочу знати через півгодини, коли мої інтеграційні тести зламаються, я хочу знати це негайно.

Зразок сценарію: Скажімо, ми маємо справу зі стандартним додатком CRUD з юридичною особою Замовника. Замовник має ім'я та адресу. На кожному рівні тестування я хочу переконатися, що логіка пошуку Клієнта правильно отримує і ім’я, і адресу.

Для тестування одиниці сховища я записую тест на інтеграцію для потрапляння в базу даних. Для тестування бізнес-правил я знущаюся з сховища, подаю відповідні дані правилам бізнесу та перевіряю, чи повертаються очікувані результати.

Що я хотів би зробити: Щоб перевірити модуль інтерфейсу користувача, я знущаюся з бізнес-правил, налаштовую очікуваний екземпляр клієнта, переглядаю і переконуюсь, що представлення містить відповідні значення для вказаного нами екземпляра.

Що я застряг: Для тестування репозиторію я пишу тест на інтеграцію, встановлюю відповідний логін, створюю необхідні дані в базі даних, відкриваю браузер, переходжу до клієнта та перевіряю, чи отримана сторінка містить відповідну значення для вказаного я екземпляра.

Я розумію, що між двома розглянутими вище сценаріями існує перекриття, але ключова різниця - це час і зусилля, необхідні для налаштування та виконання тестів.

Якщо я (або інший розробник) видаляє адресне поле з подання, я не хочу чекати тесту інтеграції, щоб виявити це. Я хочу, щоб це було виявлено та позначено в тестовому блоці, який отримує кілька разів на день.

У мене виникає відчуття, що я просто не сприймаю якусь ключову концепцію. Чи може хтось пояснити, чому бажати негайних відгуків про тест на обґрунтованість перегляду MVC - це погано? (або якщо це не погано, то не очікуваний спосіб отримати відповідь)

Просте тестування користувальницького інтерфейсу досить просто в ASP.NET MVC. По суті, все, що вам потрібно зробити, це стверджувати, що повернений HTML містить необхідні вам елементи. Хоча це гарантує, що HTML-сторінка структурована так, як ви очікуєте, вона не повністю перевіряє інтерфейс користувача.

Для правильного тестування веб-інтерфейсу потрібен такий інструмент, як Selenium, який буде використовувати браузери на вашій машині та забезпечувати належну роботу JavaScript та HTML у всіх браузерах. У Selenium є модель клієнт / сервер, щоб ви могли мати набір віртуальних машин з клієнтами Unix, Mac та Windows, а також набір браузерів, загальних для цих середовищ.

Тепер добре розроблений додаток MVC (шаблон, а не рамка) вкладає важливу логіку в моделі та контролери. Коротше кажучи, функціональність програми тестується при тестуванні цих двох аспектів. Погляди, як правило, мають лише логіку відображення і легко перевіряються візуальним оглядом. Через тонку обробку зображення і більшу частину програми, яка добре перевірена, багато людей не думають, що біль тестування шару перегляду перевищує користь, отриману ним.

При цьому, MVC має деякі приємні можливості перевірити DOM, повернений запитом. Це значно зменшує біль при тестуванні оглядового шару.

Я б не сказав, що це нахмурилося. Швидше за все, ці настрої є результатом того, що тестування модулів MVC-переглядів (принаймні, з різновидів aspx) є досить важким, тому що перегляди aspx мають занадто велику залежність від WebForms, які самі по собі є досить нестабільними. Тож аргумент іде, що не варто докладати зусиль, оскільки погляди, як правило, не такі складні.

Звичайно, перегляд може бути досить складним, тому це ваш вибір.

Я не впевнений, що це нахмурилося. Перевірка - одна з ключових переваг використання ASP.NET MVC. Перегляньте блог Стіва Сандерсона, щоб отримати додаткову інформацію про це.

Він також написав рукописну кращу книгу ASP.MVC (IMO) там. Він не тільки навчає MVC, але і перевершує його, і викладає найкращі практики, включаючи тестування.

Я думаю, мені потрібно трохи уточнити огляд тестування одиниць - ви можете побудувати тести одиниць навколо результату, поверненого з контролера (ActionResult тощо). Вам потрібно буде провести інші тестування на фактичну взаємодію з інтерфейсом та інтерфейсом користувача.

Ви можете дізнатися, як перевірити перегляд, повернутий дією контролера, як перевірити дані перегляду, повернені дією контролера, і як перевірити, чи перенаправляє вас одна дія контролера на другу дію контролера, переглянувши наступну URL-адресу, опишіть у цій короткій статті про тестування даних перегляду в MVC .