Что правильно тестировать в юнит-тестах?

#java #юнит_тесты

Предположим есть несколько классов A, B и C. Мы тестируем A. Остальные классы - моки.
У класса A есть метод, внутри которого он использует B и C, и выдает результат.  

Нужно-ли тестировать то, что класс A взаимодействует с B и C, или написать один тест,
в котором будет проверяться результат выполнения метода A?  

Делать ли такой тест в следующем случае:

class A implements B.OnBarCallback {
  private B b;

  public A(B b) {
    this.b = b;
  }

  public void foo() {
    b.bar(this);
  }

  @Override
  public void onBar() {
    // do something
  }
}

// тест вызова B
void testCallB() {
  B mockB = mock(B.class);
  A a = new A(mockB);
  a.foo();
  verify(mockB).bar(any(OnBarCallback.class));
}

// тест callback
void testACallback() {
  B mockB = mock(B.class);
  A a = new A(mockB);
  a.onBar();
  // do verify something
}


Правильно ли вручную дергать метод колбэка в тесте?
    

Ответы

Ответ 1

Если пойти совсем по правилам, то юнит тест должен тестить минимальную единицу кода.
У меня есть такое внутреннее правило - если мне вдруг понадобилось продебажить выполнение
юнит теста, так как я не понимаю, как оно работает - значит, это не юнит тест, он тестирует
слишком большой кусок кода.

Поэтому, если классы В и С достаточно большие и не тривиальные (к примеру, они читают
файлы с диска, скачивают с интернета), то лучше их замокать и в классе A тестить с
моками. А если методы B/C складывают два числа, то я не вижу особой причины их мокать.


  Нужно-ли тестировать то, что класс A взаимодействует с B и C


Но никто не отменяет тестов взаимодействия классов вместе. Просто это называется
уже интеграционные тесты. И они также нужны и полезны.


  или написать один тест, в котором будет проверяться результат выполнения метода A?


А вот сколько тестов написать - это уже философский вопрос. Но одного обычно мало бывает.