Чи слідування TDD неминуче призводить до DI?

14

Я навчився одночасно робити тест-керовану розробку (TDD), впорскування в залежності (DI) та інверсію управління (IoC). Коли я пишу код за допомогою TDD, я завжди закінчую використання DI в конструкторах мого класу. Мені цікаво, чи це через те, як я навчився робити TDD, чи це природний побічний ефект від TDD.

Отже, моє запитання таке: чи слідкуючи за принципами TDD та написанням тестів, що не залежать від зовнішніх служб, неминуче призводить до DI?

tdd dependency-injection inversion-of-control

— Жиль
джерело

8

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

— програміст

2

То про яку мову йде мова? DI / і т.д. необхідні в Java, але це через обмеження мови - такі мови, як Python, не потребують, оскільки можуть тестувати залежність виправлення мавп у тестах.

— Ізката

@Izkata: Я погоджуюся з тим, що DI є вирішенням обмеження мови; але маніпулювання мавпами не обов'язково одне і те ж на менш жорстких мовах. Серед інших способів я віддаю перевагу першокласним функціям, що дозволяє природно робити те, що DI наближається до дисципліни.

— Хав'єр

19

Чи невідворотно призводить до тестування TDD та тестування блоків, які не залежать від баз даних або зовнішніх служб?

Для широких визначень DI так. Заняття у вакуумі не існують, тому їм потрібно якось заповнити свої залежності. Іноді просто надавати цінність добре. Іноді потрібно надати макет в конструкторі. Іноді через контейнери IoC. Іноді через приватний тестовий доступ. Це все вводить якусь тестову річ у клас, щоб вона могла працювати ізольовано.

— Теластин
джерело

9

Для людей, які вже знають про DI, але просто ніколи не бачили сенсу, я думаю, що одиничне тестування майже незмінно призведе до використання DI.

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

— Карл Білефельдт
джерело

8

Тестування одиниць призведе до DI (оскільки воно змушує вас створювати одиниці, що з’єднані слабко). TDD не обов'язково, оскільки TDD також може використовуватися для створення тестів пошарово, замість "дослівних" одиниць тестів. Дивіться цю статтю

http://stephenwalther.com/archive/2009/04/11/tdd-tests-are-not-unit-tests.aspx

для пояснення відмінностей.

— Док Браун
джерело

1

+1 для "TDD не є UT". Також для визнання того, що екстремальне роз'єднання є загальним результатом UT, а не (обов'язково) TDD.

— Хав'єр

3

Так і ні: TDD призводить до написання добре структурованого коду, який сам призводить до DI.

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

— Тім
джерело

Не могли б ви уточнити ні частину своєї відповіді так і ні? Як можна зробити TDD без DI.

— Жиль

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

— Тім

0

Як уже вказувалося в інших відповідях, TDD не вимагає одиничних тестів. Ви також можете добре писати інтеграційні / функціональні тести, роблячи TDD. З декількох способів застосувати TDD, створення одиничних тестів було б способом "підробляти, поки ти не зробиш" (детальніше див. Книгу Кента Бека).

Що стосується "TDD неминуче призводить до DI", це точно не відповідає. Що потрібно для написання одиничних тестів, це ізолювати одиницю, що перевіряється, від реалізації її зовнішніх залежностей. І це можна зробити так само легко з використанням DI або без нього. Найкращий спосіб, мабуть, - використовувати належний інструмент для ізоляції / знущань.

— Роджеріо
джерело

Але для того, щоб використовувати макети, чи не обов’язково ви вводити залежності в класі?

— Жиль