Spock - захват аргументов метода в частном вызове метода тестируемого класса - PullRequest
Новая
       79

Spock - захват аргументов метода в частном вызове метода тестируемого класса

0 голосов
/ 05 марта 2020

Я пытаюсь проверить мой класс обслуживания ниже 

@Service
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class TaskTemplateService {
  @NonNull
  TaskTemplateRepository taskTemplateRepository;

  public void doStuff() {
    List<MyObject> list;
    doOtherStuff(list)
  }

  private void doOtherStuff(List <MyObject>) {
    //do stuff
  }
}

Когда я тестирую реальный TaskTemplate, как я могу захватить то, что передается doOtherStuff?

1 Ответ

0 голосов
/ 06 марта 2020

Вы не можете и с чего бы это пошли?

Хорошее тестирование означает определение поведения общедоступного c интерфейса устройства. Частные методы должны быть опровергнуты путем косвенного тестирования. Если это невозможно, то у вас либо мертвый, недоступный код, либо проблема с дизайном, и вы должны выполнить рефакторинг.

Кстати, техническая причина, по которой вы не можете высмеивать / заглушать приватные методы, заключается в том, что большинство инструментов насмешки, а также встроенные в особенности Spock, используйте динамические прокси c (DP) для реализации имитации. DP технически являются подклассами, но частные методы никогда не могут быть расширены или даже просмотрены подклассами или вызваны ими или из других классов, отсюда и термин «частный». Следовательно, фиктивный подкласс не может проверять взаимодействия с закрытыми методами.

Как именно вы должны изменить дизайн своего класса, чтобы сделать его тестируемым, действительно зависит от того, почему вы хотите «захватить» аргумент метода, как вы говорите. Вам нужно заменить его на макет? Вам нужно изменить или проверить содержимое исходного объекта?

  • Если объект имеет центральное значение, и вам нужно заменить или проверить его, почему бы не сделать его инъекционным вместо создания это как локальная переменная, герметично изолирующая его от внешнего мира и делающая его непроверяемым?

  • Или, возможно, в вашем случае вы могли бы сделать закрытый метод защищенным или ограниченным по пакетам, чтобы сделать это тестируемым Тогда, по крайней мере, можно создать для него макет, и вы сможете зафиксировать аргумент или заглушить результат.

Я в основном размышляю здесь, потому что ответ действительно зависит от того, что стоит за //do stuff то есть та самая информация, которую вы скрываете в своем примере кода.

...