Как замокать метод структуры, который вызывается в другом методе этой же структуры в Golang?

Question

[Всеволод Калошин]

Всем привет!
При написании тестов столкнулся с одной проблемой. Есть тестируемый код;

Do() error
}
type MyInterface interface {
   MethodA() error
   MethodB() error
}
type MyStruct struct {
  OtherStruct OtherInterface
}
func(s *MyStruct) MethodA() error {
  return s.MethodB()
}
func(s *MyStruct) MethodB() error {
  return s.OtherStruct.Do()
}

И код, который тестирует MethodB

ype MockOtherStruct struct {
  Do_Error error
}
func (t *MockOtherStruct) Do() error {return t.Do_Error}


TestMyStruct_MethodB(t *testing.B) {
  expectedError = nil
  mos := &MockOtherStruct{
    Do_Error: nil
  }
  ms := MyStruct{
   OtherStruct: mos,
  }
  err := ms.MethodB()
  if err != expectedError {
    t.Fatal(err)
  }      
}

Как мне протестировать MethodA, замокав MethodB?
Данный пример простой, так как в реальном коде, структура может иметь множество переменных-структур, которые имплемитируют разные интерфейсы. Также логика различных методов может быть довольно таки сложна, чтобы получилось легко использовать замоканные переменные.

Answer 1

[Евгений Иваха]

Не надо мокать, нужно упрощать логику.

Кроме того, *testing.B используется для бенчмарков. Нужно использовать *testing.T для тестирования.

Comments

[Всеволод Калошин]

Опечатался с B.
По-другому не получается, так как происходит неоправданное дублирование кода.

[Евгений Иваха]

Если код получается слишком сложным, значит что-то в нём не так. Проблема моков в том, что при тестировании, тестируешь не нужный сервис, а свои моки, в которых тоже может быть ошибка.
Do_Error — тоже совсем не гошное имя переменной.

Думаю, нужно пересмотреть алгоритм. Наверняка всё можно сильно упростить.

Answer 2

[Никита]

Смотрите в сторону testify