Не нарушает ли самопроверка шаблон проверки принципа единой ответственности?

Question

За последние годы я несколько раз использовал шаблон самопроверки. Как я недавно объяснял это кому-то, они утверждали, что это нарушает SRP. Аргумент заключается в том, что теперь класс теста можно изменить по одной из двух причин: при изменении теста или при изменении сигнатуры метода на интерфейсе, который этот тест реализует. Подумав некоторое время, кажется, что это правильная оценка, но я хотел узнать мнение других людей. Мысли

Ссылка: http://www.objectmentor.com/resources/articles/SelfShunPtrn.pdf

Answer 1

Я считаю, что тестовый класс технически нарушает SRP, но не нарушает дух SRP.Альтернатива самопрошиванию - иметь фиктивный класс, отдельный от тестового класса.

С отдельным фиктивным классом можно подумать, что он полностью самодостаточен и удовлетворяет SRP, однако семантическая связь с классом имитацииатрибуты все еще там.Так что, на самом деле, мы не достигли никакого значимого разделения.

Взяв пример из PDF:

public class ScannerTest extends TestCase implements Display
{
  public ScannerTest (String name) {
    super (name);
  }
  public void testScan () {
    // pass self as a display
    Scanner scanner = new Scanner (this);
    // scan calls displayItem on its display
    scanner.scan ();
    assertEquals (new Item (“Cornflakes”), lastItem);
  }
  // impl. of Display.displayItem ()
  void displayItem (Item item) {
    lastItem = item;
  }
  private Item lastItem;
}

Теперь мы создаем макет:

public class DisplayMock implements Display
{
  // impl. of Display.displayItem ()
  void displayItem (Item item) {
    lastItem = item;
  }

  public Item getItem() {
     return lastItem;
  }
  private Item lastItem;
}

public class ScannerTest extends TestCase
{
  public ScannerTest (String name) {
    super (name);
  }
  public void testScan () {
    // pass self as a display
    DisplayMock dispMock = new DisplayMock();
    Scanner scanner = new Scanner (dispMock );
    // scan calls displayItem on its display
    scanner.scan ();
    assertEquals (new Item (“Cornflakes”), dispMock.GetItem());
  }
}

В практическом плане (ИМХО) более высокая связь TestClass с DisplayMock является большим злом, чем нарушение SRP для TestClass.Кроме того, с использованием фальшивых фреймворков эта проблема полностью исчезает.

РЕДАКТИРОВАТЬ Я только что столкнулся с кратким упоминанием паттерна самосшунтирования в превосходной книге Роберта К. Мартина AgileПринципы, образцы и практики в C # .Вот фрагмент из книги:

Итак, у парня, который придумал SRP (о котором подробно говорится в той же книге), нет никаких сомнений, используя selfшунт шаблон.В свете этого я бы сказал, что при использовании этого паттерна вы достаточно защищены от ООП.

Answer 2

По моему мнению, является нарушением, но очень незначительным.

Ваш тестовый класс теперь является тестовым классом и зависимостью для всего, что вы тестируете.

Однако, это плохо? Для пары простых тестов, вероятно, нет. По мере роста количества тестовых случаев вы, вероятно, захотите провести рефакторинг и использовать фиктивный класс, чтобы отделить некоторые проблемы. (Как говорит ссылка, которую вы вставили, самообман - трамплин для насмешек). Но если количество тестовых случаев остается статичным и низким, в чем проблема?

Я думаю, что требуется небольшой прагматизм. Это нарушает SRP? Да, но, наверное, не так много, как часть кода в тестируемой системе. Вам нужно что-нибудь сделать с этим? Нет, пока код ясен и удобен в обслуживании, что для меня всегда является практическим результатом. SRP - это руководство, а не правило.

Answer 3

Я предпочитаю немного больше контролировать макеты / заглушки, которые я создаю. Когда я попытался использовать шаблон самоконтроля, я в конечном итоге сделал свой тестовый класс более сложным. Создавая макеты как локальные в тестовом методе, я получил более чистый код.

FWIW, если вы не используете что-то мощное, такое как C # (или python или эквивалентный), ваш тестовый код изменится, когда вы измените интерфейс.

Answer 4

Если реализуемый или шунтируемый интерфейс изменяется, относительно вероятно, что набор тестов также должен будет измениться.Поэтому я не вижу в этом нарушения SRP.