Чи необхідна ін'єкція залежності для одиничного тестування?

Чи важливе використання ін'єкцій залежностей (DI) для тестування одиниці?

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

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

Я сам багато використовував, наприклад, інтерфейси та фабрики, перш ніж дізнатися про DI. Фактичне ім'я заводського класу, можливо, було прочитане з конфігураційного файлу або передано до SUT як аргумент.

Інший підхід - використання одиночних клавіш (або загальнодоступних даних загалом). Так, я знаю, що це взагалі не рекомендується багатьма (включаючи мене). Однак це може бути життєздатним у конкретних ситуаціях, особливо якщо одиночний містить статичні дані конфігурації, які не є специфічними для тестового випадку, але відрізняються між виробничим та тестовим середовищем. Звичайно, у нього є свої відомі проблеми, тому DI перевершує, якщо ви можете ним користуватися. Але часто (наприклад, у застарілих системах) ви не можете.

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

Роз'єднання є важливим для тестування одиниць. DI - чудовий спосіб досягти роз’єднання.

Залежно від технологій, які ви використовуєте, ви можете ізолювати залежності, не використовуючи DI. Наприклад, у світі .NET Moles дозволяє ізолювати залежності без шаблону DI.

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

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

Ні, DI не є важливим для одиничного тестування, але він дуже допомагає.

Ви можете використовувати фабрики чи локатори та тестувати так, як це було б із DI (просто не настільки елегантно і вимагало б більше налаштувань).

Крім того, Mock Objects буде важливим у застарілих системах, де багато викликів делеговано функціям замість залежностей. (Макетні об’єкти також можуть широко використовуватися в належному налаштуванні)

Можуть бути налаштування, де тестування майже неможливо. Але це не ґрунтується на тому, використовується ін'єкція залежності чи ні.

Ні , введення залежності не є істотним для одиничного тестування.

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

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

 bool hasPermissionToTransferMoney(Employee employee, Account from, Account to, Money amount)
 {
     if (amount > 100 && employee.isStudent())
        return false;
     if (to.getOwner().getFamiliyName() == employee.getFamilyName() && ...
        return false; // cannot transfer money to himself;
     ...
 }

Після відокремлення збору даних та обчислення:

 bool hasPermissionToTransferMoney(Employee employee, Account from, Account to, Money amount)
 {
     return hasPermissionToTransferMoney(employee.isStudent(), employee.getFamilyName(), to.getOwner().getFamilyName(), ...);
 }

 // the actual permission calculation
 static bool hasPermissionToTransferMoney(boolean isStudent, string employeeFamilyName, string receiverFamilyName, ...)
     if (amount > 100 && isStudent)
        return false;
     if (receiverFamilyName == employeeFamiliyName && ...
        return false; // cannot transfer money to himself
     ...
 }

Розрахункову частину можна легко перевірити без введення залежності.

• Введення залежності не є істотним для одиничного тестування

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

Так, існують альтернативи використанню ДІ для ізоляції.

Однією з альтернатив є використання фабрик або ServiceLocator, які можна налаштувати з тестів для повернення макетних об'єктів замість реальних.

Інша полягає у використанні підходящого ізоляційного каркаса або макетного інструменту. Такі інструменти існують практично для кожної сучасної мови програмування (як мінімум для Java, C #, Ruby та Python). Вони можуть ізолювати клас, який тестується, від реалізації інших класів / типів, навіть коли тестований клас безпосередньо підтверджує його залежності.