Методи тестування блоку, які викликають постачальників веб-сервісів

У мене є клас з одним публічним методом Send()та кількома приватними методами. Він викликає пару веб-служб і обробляє відповідь. Обробка проводиться приватними методами.

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

Я також вважаю, що приватні методи не повинні перевірятися одиницею, але якщо я просто перевіряю метод Send (), мій код не перевіряється ізольовано і залежить від резонсери постачальника.

Чи повинен я потім оприлюднювати свої приватні методи, щоб я міг перевірити їх з глузливими відповідями? Це здається поганою практикою, оскільки мені потрібно лише називати їх класом.

Вибачте, якщо це основне питання, я досить новий для одиничного тестування.

Я використовую c # та VS2010

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

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

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

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

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

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

Для хорошого допису в різних C # глузливих структурах див наступну тему SO:

/programming/37359/what-c-mocking-framework-to-use

РЕДАКТУВАННЯ: Для відверто чутливих я вважаю, що я нехтував згадкою про DbUnit або інші транзакційні інструменти, які можуть повернути зміни бази даних в кінці тесту. Вони також є повторюваними і можуть бути агностичними для оточуючих з генерованими тестовими даними, тому глузлива рамка в цьому випадку не потрібна.