Поступові підходи до ін'єкції залежності

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

Один із підходів, який я маю на увазі, - це просто переміщення всіх "нових" викликів у власні методи, наприклад:

public MyObject createMyObject(args) {
  return new MyObject(args);
}

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

Це хороший підхід? Чи є недоліки?

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

Один недолік, який мені щойно стався: якщо у вас є реальні підкласи, які потрібно перевірити, ви не можете повторно використовувати тестовий підклас, який ви написали для батьківського класу. Вам доведеться створити тестовий підклас для кожного реального підкласу, і він повинен буде замінити однакові функції створення.

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

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

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

Люди з Guice рекомендують використовувати

@Inject
public void setX(.... X x) {
   this.x = x;
}

для всіх властивостей, а не просто додавання @Inject до їх визначення. Це дозволить вам ставитися до них як до звичайних бобів, що ви можете newпід час тестування (та встановлення властивостей вручну) та @Inject у виробництво.

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

Тож мій новий тестовий клас одиниць матиме 2 конструктори:

public MyClass() { 
  this(new Client1(), new Client2()); 
}

public MyClass(Client1 client1, Client2 client2) { 
  this.client1 = client1; 
  this.client2 = client2; 
}

Ви можете розглянути ідіому "гетьтер створює", поки не зможете використовувати введену залежність.

Наприклад,

public class Example {
  private MyObject myObject=null;

  public MyObject getMyObject() {
    if (myObject==null) {
      myObject=new MyObject();
    } 
    return myObject;
  }

  public void setMyObject(MyObject myObject) {
    this.myObject=myObject;
  }

  private void myMethod() {
    if (getMyObject().doSomething()) {
      // Instance automatically created
    }
  }
}

Це дозволить вам рефакторировать внутрішньо, щоб ви могли посилатися на мій об'єкт через геттер. Вам ніколи не потрібно дзвонити new. Надалі, коли всі клієнти налаштовані на дозвіл введення залежності, тоді все, що вам потрібно зробити, - це видалити код створення в одному місці - геттера. Установник дозволить вам вводити макетні об’єкти за потребою.

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

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