В приложении много алгоритмов построенно с помощью Visitor'а, при чем Visit перегружен под конкретные типы. А когда начали писать тесты поняли, что писать моки под конкретные типы не вариант... Я правильно понимаю, что иного пути, кроме как из каждого типа выделить интерфейс и переписать в терминах интерфейса нет?

Здравствуйте, vladpol, Вы писали:

V>В приложении много алгоритмов построенно с помощью Visitor'а, при чем Visit перегружен под конкретные типы. А когда начали писать тесты поняли, что писать моки под конкретные типы не вариант... Я правильно понимаю, что иного пути, кроме как из каждого типа выделить интерфейс и переписать в терминах интерфейса нет?

А вариант не писать моки даже не рассматривался?

Здравствуйте, vladpol, Вы писали:

V>В приложении много алгоритмов построенно с помощью Visitor'а, при чем Visit перегружен под конкретные типы. А когда начали писать тесты поняли, что писать моки под конкретные типы не вариант... Я правильно понимаю, что иного пути, кроме как из каждого типа выделить интерфейс и переписать в терминах интерфейса нет?

В случае с визитором один unit это сама древообразная структура + visitor. Нет смысла тестировать отдельные вызовы, есть смысл тестировать результат применения визитора.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, vladpol, Вы писали:

V>>В приложении много алгоритмов построенно с помощью Visitor'а, при чем Visit перегружен под конкретные типы. А когда начали писать тесты поняли, что писать моки под конкретные типы не вариант... Я правильно понимаю, что иного пути, кроме как из каждого типа выделить интерфейс и переписать в терминах интерфейса нет?

G>В случае с визитором один unit это сама древообразная структура + visitor. Нет смысла тестировать отдельные вызовы, есть смысл тестировать результат применения визитора.

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

Здравствуйте, vladpol, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, vladpol, Вы писали:

V>>>В приложении много алгоритмов построенно с помощью Visitor'а, при чем Visit перегружен под конкретные типы. А когда начали писать тесты поняли, что писать моки под конкретные типы не вариант... Я правильно понимаю, что иного пути, кроме как из каждого типа выделить интерфейс и переписать в терминах интерфейса нет?

G>>В случае с визитором один unit это сама древообразная структура + visitor. Нет смысла тестировать отдельные вызовы, есть смысл тестировать результат применения визитора.

V>Публичный метод принимает на вход параметр базового типа и пропускает его через визитор, раскладывая по конкретным типам и выполняя ддля каждого некие действия. Получается, что бы оттестировать результат мне нужно создать моки на каждый дочерний тип, а это затруднительно
А зачем моки?

Здравствуйте, vladpol, Вы писали:

V>В приложении много алгоритмов построенно с помощью Visitor'а, при чем Visit перегружен под конкретные типы. А когда начали писать тесты поняли, что писать моки под конкретные типы не вариант... Я правильно понимаю, что иного пути, кроме как из каждого типа выделить интерфейс и переписать в терминах интерфейса нет?

Какой смысл в интрефейсах? В качестве аргумента с типом интерфейса все равно придется что-то передавать. Если это будет конкретный тип — передавайте его сейчас, если мок — зачем интерфейсы?

Вы не договорили, почему возникла идея писать моки и почему вы решили, что это не вариант?

Здравствуйте, vladpol, Вы писали:

V>Публичный метод принимает на вход параметр базового типа и пропускает его через визитор, раскладывая по конкретным типам и выполняя ддля каждого некие действия. Получается, что бы оттестировать результат мне нужно создать моки на каждый дочерний тип, а это затруднительно

Вы хотите тестировать каждое действие? Значит вам надо передать нужный ему тип. Вариантов-то нет, чтобы оттестировать метод надо его выполнить (статический анализатор мы тут не рассматриваем), чтобы выполнить надо вызвать, чтобы вызвать — передать аргумент.