= ClassImpl.class.getDeclaredMethod("myMethod",
String.class, String.class, String.class, Tariff.class);
myMethod.setAccessible(true);
boolean output =
(boolean) myMethod.invoke(validator, "a", "b", "c", tariff);
Где validator это
@Autowired
private MyValidatorInterface validator;
Проблема в том что (внезапно) на invoke говорится что это не его метод - логично потому что у интерфейса есть только его методы
А у имплентации они + private. Как поступить дальше чет хз. Только ради бога - я знаю что тестить private методы это очень плохо и за такое надо бить по рукам, но лучше скажите как протетстить, спасибою
может вместо ClassImpl.class взять класс прямо у валидатора, через validator.getClass()?
Либо лыжи не едут, либо я дурак Но вышла (внезапно) com.sun.proxy.$Proxy248
ах да, про прокси-то я не подумал
Мне еще предлагали с метода снять private и оставить package + добавить @VisibleForTesting, но что-то метод все равно не видно в тесте
Оставляя за скобками приватность методов, почему бы не взять метод у интерфейса MyValidatorInterface?
в порядке бреда можно еще переключить создание бина с proxy на cglib. тогда в классе все еще будет какая-то хрень, но по крайней мере это будет наследник вашей имплементации, а не враппер. но делать так стоит только в тест-конфиге, прод может пострадать от внезапного непротестированного переключения
Потому что в таком случаем мы получим ровно те методы что объявлены в интерфейсы Private же метод есть только в классе реализации этого интерфейса
я не помню точно, но есть вероятность, что если инжектить через конструктор, то там будет другое поведение
а зачем тестировать приватные методы ?
кстати, а сделать метод package-private не проще? или нет способа изменять тот код?
я всегда так делаю, если нужна какая-то дырка для теста, то package-private метод с пометкой "только для теста" и вперёд. Как я вижу это вполне нормальная практика (во всяком случае это не я её придумал =) )
Обсуждают сегодня