Тестування з усіма існуючими залежностями все ще важливо, але це більше в царині інтеграційного тестування, як сказав Джеффрі Фауст.
Один з найважливіших аспектів тестування одиниць - зробити тести надійними. Якщо ви не вірите, що проходження тесту дійсно означає, що речі хороші і що невдалий тест справді означає проблему з виробничим кодом, ваші тести не є настільки корисними, як можуть бути.
Для того, щоб ваші тести були достовірними, ви повинні зробити кілька речей, але для цієї відповіді я зосередиться лише на одному. Ви повинні переконатися, що їх легко запустити, так що всі розробники можуть легко запустити їх перед тим, як перевірити код. "Легкий запуск" означає, що ваші тести виконуються швидко та не потрібна широка конфігурація чи налаштування, щоб змусити їх працювати. В ідеалі кожен повинен мати можливість перевірити останню версію коду, запустити тести відразу та побачити, як вони проходять.
Обмеження залежностей від інших речей (файлова система, база даних, веб-сервіси тощо) дозволяє уникнути необхідності конфігурації та робить вас та інших розробників менш сприйнятливими до ситуацій, коли ви спокушаєтесь сказати "Ой, тести не вдалися, бо я цього не роблю" не налаштуйте мережеву частку. Ну добре, я запускаю їх пізніше ".
Якщо ви хочете перевірити, що ви робите з деякими даними, ваш пристрій перевіряє код коду ділової логіки не має значення, як ви отримаєте ці дані. Бути в змозі перевірити основну логіку вашої програми, не залежно від підтримки таких матеріалів, як бази даних, є дивним. Якщо ви цього не робите, ви пропадаєте.
PS Я мушу додати, що напевно можливо переобладнати в ім'я довіреності. Тест-керування вашою програмою допомагає пом'якшити це. Але в будь-якому випадку, погана реалізація підходу не робить підхід менш валідним. Що-небудь можна зловживати і перестаратися, якщо хтось не запитує "чому я це роблю?" під час розвитку.
Що стосується внутрішніх залежностей, то справи стають трохи каламутними. Те, як мені подобається думати про це, полягає в тому, що я хочу максимально захистити свій клас від зміни з неправильних причин. Якщо у мене є така програма, як щось подібне ...
public class MyClass
{
private SomeClass someClass;
public MyClass()
{
someClass = new SomeClass();
}
// use someClass in some way
}
Мені взагалі все одно, як SomeClassце створено. Я просто хочу його використовувати. Якщо SomeClass змінюється і тепер потрібні параметри для конструктора ... це не моя проблема. Мені не потрібно було міняти MyClass, щоб його вмістити.
Тепер це стосується лише дизайнерської частини. Що стосується одиничних тестів, я також хочу захистити себе від інших класів. Якщо я тестую MyClass, мені подобається знати, що немає зовнішніх залежностей, що SomeClass в якийсь момент не ввів з'єднання з базою даних або іншим зовнішнім посиланням.
Але ще більша проблема полягає в тому, що я також знаю, що деякі результати моїх методів залежать від результатів якогось методу на SomeClass. Не маючи глузування / заглушення SomeClass, я, можливо, не можу змінити цей вклад у попит. Якщо мені пощастить, я, можливо, зможу скласти своє середовище всередині тесту таким чином, що він спричинить правильну відповідь від SomeClass, але таким чином вводить складність у мої тести та робить їх крихкими.
Перезапис MyClass для прийняття екземпляра SomeClass в конструкторі дозволяє мені створити підроблений екземпляр SomeClass, який повертає потрібне мені значення (або через глузливий фреймворк, або за допомогою макетів вручну). Як правило , в цьому випадку не потрібно вводити інтерфейс. Робити це чи ні, багато в чому це особистий вибір, який може бути продиктований мовою вибору (наприклад, інтерфейси скоріше на C #, але в Ruby вам точно не знадобиться).