Тестування підрозділу класу, який використовує DI без тестування на внутрішніх

У мене є клас, який реконструюється в 1 основному класі та в 2 менших класах. Основні класи використовують базу даних (як це робить багато моїх класів) і надсилають електронний лист. Таким чином, у основного класу є IPersonRepositoryі IEmailRepositoryвводиться ін'єкція, яка в свою чергу надсилає до 2-х менших класів.

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

Але , як клас використовує IPersonRepositoryі IEmailRepositoryя МАЮ вказати (макет / манекен) результати для деяких методів для IPersonRepository. Основний клас обчислює деякі дані на основі наявних даних і повертає їх. Якщо я хочу це перевірити, я не бачу, як я можу написати тест, не вказуючи, що IPersonRepository.GetSavingsByCustomerIdreturn x. Але тоді мій блок-тест "знає" про внутрішні розробки, тому що він "знає", які методи знущатися, а які ні.

Як я можу перевірити клас, у якого введені залежності, не знаючи тесту про внутрішню?

фон:

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

Тепер я бачив презентацію про теорію (яку я чув раніше), що тест не повинен знати про реалізацію. Спочатку тому, що ви не тестуєте, як це працює, а також тому, що, коли ви зараз змінюєте реалізацію, всі тести блоку виходять з ладу, оскільки вони "знають" про реалізацію. Хоча мені подобається, що концепція тестів не знає про реалізацію, я не знаю, як її виконати.

Основний клас обчислює деякі дані на основі наявних даних і повертає їх. Якщо я хочу це перевірити, я не бачу, як я можу написати тест, не вказуючи, що IPersonRepository.GetSavingsByCustomerIdreturn x. Але тоді мій блок-тест "знає" про внутрішні розробки, тому що він "знає", які методи знущатися, а які ні.

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

Як я можу перевірити клас, у якого введені залежності, не знаючи тесту про внутрішню?

Ви можете прийняти два рішення, щоб вирішити це порушення:

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

Цей підхід має перевагу в простоті механізму DI, але він може створити багато роботи, якщо ваш інтерфейс визначає багато методів.

2) Не вводити IPersonRepositoryабо вводити GetSavingsByCustomerIdметод, або не вводити значення економії. Проблема з ін'єкцією цілих реалізацій інтерфейсу полягає в тому, що ви ін'єктуєте ("скажіть, не запитуйте") систему "запитати, не кажи", змішуючи два підходи. Якщо ви використовуєте "чистий DI" підхід, метод повинен передбачити (розповісти) точний метод для виклику, якщо він хоче значення економії, а не присвоєння об'єкту (який він повинен ефективно вимагати, щоб метод викликав).

Перевага такого підходу полягає в тому, що він уникає необхідності знущань (крім методів тестування, які ви вводите в тестований метод). Недоліком є ​​те, що він може спричинити зміну підписів методів у відповідь на зміни вимог методу.

Обидва підходи мають свої плюси і мінуси, тому виберіть той, який найкраще відповідає вашим потребам.

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

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

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

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

Тестові одиниці, як правило, є тестами білого поля (у вас є доступ до реального коду). Тому нормально знати внутрішню інформацію до певної міри, однак для початківців легше це не робити, тому що не слід перевіряти внутрішню поведінку (наприклад, "виклик методу спочатку, потім b, а потім знову").

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