Як здійснити перевірку веб-форм веб-форм?

Як здійснити перевірку веб-форм веб-форм? Мені здається, що оскільки стільки цього залежить від стану та введення користувача, це було б неможливо.

Якщо це неможливо, чи є дійсна автоматизована альтернатива?

Так, ти можеш. Ви просто повинні бути обережними, щоб добре розділити свої проблеми. Коротше кажучи, ви повинні видалити всю свою логіку з коду і відставити її в інших класах.

Є два загальних способи зробити це.

Найпростіший спосіб - переосмислити всі ваші обробники подій у розділі "Яку інформацію мені дає система? Яку інформацію мені потрібно заповнити на сторінці?" а потім надати клас обслуговування, який здійснює цю конверсію.

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

Складніший, але більш ефективний спосіб - це використовувати модель Presenter Model View . Коли ми спробували це, ми виявили, що презентатори швидко приєдналися до рамки, і чим більше ми розробляли MVP, тим зрозуміліше було, що MVP дійсно хотів бути MVC, але не міг бути.

Однак, інші зробили це дуже успішно - є навіть доступний фреймворк webformsmvp для зняття важкого підйому - тому ваш пробіг може відрізнятися.

Цілком очевидно, що ціла сторінка веб-форм не є одиницею, і тому не може бути перевірена одиницею. Однак ви можете зробити деякі автоматичні тести:

• тестування окремих компонентів сторінки (будь-які методи, що виконують фактичну логіку)
• компоненти тестових одиниць, використовувані сторінкою (користувацькі елементи керування, основні бізнес-логіки тощо)
• автоматичне тестування функціональності (дистанційним керуванням браузером або надсиланням HTTP-запитів через щось на зразок cURL)
• автоматичне тестування на проникнення (на вашій сторінці є інструменти, які намагатимуться знайти можливі точки введення та автоматично запускати нешкідливі, але помітні напади ін'єкції
• тестування навантаження
• перевірка макета у відповідності зі списком зручностей та побутових точок кулі (хоча це дуже важко автоматизувати; зазвичай це зручніше робити це вручну раз у раз)

Вибачте за те, що пропустили частину питання "одиниця" ...

SeleniumHQ - ваш друг для тестів з передньої частини. Це не одиничне тестування, більше схоже на тестування чорної скриньки. Вам ще потрібно думати про вагомі тестові справи ...

Якщо говорити з досвіду: Тільки якщо це зроблено правильно. Під "правильним" я маю на увазі мінімальний відставання коду і щось подібне до вищезгаданого Model-View-Presenter, щоб зробити веб-форму "німим". Звичайно, це виявляється дуже складно з програмами Brownfield, оскільки вони не були розроблені з цим на увазі, і це майже геркулецьке зусилля переробити / переписати сторінки, щоб використовувати його.

вати

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

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

http://watin.org/ - ще один інструмент веб-тестування, але для C # /. NET. Ви пишете тести як одиничні тести:

[Test] 
public void SearchForWatiNOnGoogle()
{
  using (var browser = new IE("http://www.google.com"))
  {
    browser.TextField(Find.ByName("q")).TypeText("WatiN");
    browser.Button(Find.ByName("btnG")).Click();

    Assert.IsTrue(browser.ContainsText("WatiN"));
  }
}

Наразі вона заснована на IE, але має деяку експериментальну підтримку для Firefox та Chrome. Ви можете значно автоматизувати все, що б ви робили в ручних тестах, включаючи взаємодію з Javascript.

Ви не можете реально перевірити веб-сайт просто через те, що веб-запити трапляються на дроті (або через стек TCP). Таким чином, тести не відповідають визначенню "одиничне випробування", вони, швидше за все, будуть тестами.

Для таких типів тестів ви можете використовувати набір типу Selenium, який запускає веб-браузер за кадром. Слово попередження, однак: зазвичай такий вид тестування дуже важкий і непередбачуваний, оскільки є багато рухомих частин!

Що ще цікавіше, мене трохи хвилює, чому вам взагалі потрібно перевірити веб-форми. Чи ви не вкладаєте занадто багато логіки в коді позаду і маєте анемічну ділову логіку випадково?

Жасмін

Протягом останніх 5 років Жасмін став ключовим інструментом для тестування модулів. Він часто включається в тестування автоматичної збірки за допомогою Node та npm

Per https://en.wikipedia.org/wiki/Jasmine_(JavaScript_testing_framework) :

Жасмін - це тестова основа з відкритим кодом для JavaScript. [2] Він спрямований на роботу на будь-якій платформі з підтримкою JavaScript, не втручатися в додаток та IDE та мати синтаксис, який легко читається. На нього сильно впливають інші рамки тестування блоків, такі як ScrewUnit, JSSpec, JSpec та RSpec. [3]

Незважаючи на всі згадки про javascript, він також може бути використаний для одиничного тестування простої веб-форми.

ASP.NET

Розробляючи сайт ASP.NET, ми мали змогу запустити тести на:

• Домен
• BL контролери / презентатори
• кодовий код сторінок веб-форм

Все це можливо TDD, залежно від вашої архітектури. Єдине, що ви не можете перевірити, це макет файлу розмітки.