Привет, вопрос по Rx. Есть функция, в которой создаётся completable

и происходит подписка на него. Как её можно протестить? Наружу ничего не торчит, и, например использовать blockingSubscribe я не могу.

https://stackoverflow.com/questions/41699020/how-to-assert-if-a-completable-has-been-subscribed-completed-rxjava2

Функция ничего не возвращает, вся реактивщина в ней, ни test ни runblocking я не могу использовать. По ссылка у задающего вопрос возвращается Completable.

Ну комплитабле в принципе ни чего не возвращает

Ну можно сам completable вернуть и подписаться с помощью blockingSubscribe()/

Я просто не понимаю зачем с комплитаблом чтот изобретать. Он как тип добавили в базу? Да, нет.

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

Из определения это процессор. (не должен ждать кто её запускает)

Один из принципов создания тестируемого асинхронного кода - это абстракция планировщика/диспатчера и подстановка его специальной синхронной версии для тестов. Лучше всего через конструктор тестируемого класса. Например из этой статьи можно использовать некоторые паттерны.

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

Так а блокингСабскрайб чем не подошел?

Тем что в бизнес логике сабскрайб должен быть не блокинг, а в тесте его не на чем вызывать

Почему не можете менять класс то?) Тогда нужна конкретика, что за функция там есть у вас, смотря какой completable создаёт и как выглядит вся цепочка (судя по всему она целиком в методе).

Там все сложно на самом деле. Комплитабл запускает саспенд функцию которая выполняет основную работу, т.к. Легаси на rx, но постепенно добавляют корутины.

Вам не кажется, что это то ещё тестить обертку в виде комплитабле над суспенд функциями. Ну в целом это звучит уже как-то...

Безусловно это не лучшее решение, но оно не моё и что-то с этим сделать я не могу) кроме как протестить и сдать таску

Либо обособленнон добавление. Именно обособленно, а не попытки все это смешать в винигрет

То есть вы только пишите тесты к имеющемуся коду, а сам его трогать не можете?) К сожалению, чтобы написать тесты код должен быть написан тестируемым.

А так если по сикрету всему свту это чьё решение? Ну я понимаю ещё миграцию частичную когда новые сервисы суспенд, старые ещё на рхе. И они как бе независимы и ждут своего часа (когда нить)))

Нет, конкретно эту функцию написал я, но она использует другую, которая позволяет запускать саспенды в сервисе, в котором нет корутин контекста.

Ну примерно так и есть, запросы к БД - саспенд, а код который их использует не имеет корутин контекста, и с помощью вот такого костыля все работает.

Честно вот прям хз как это все тестить. Не сталкивался с такими оборотами. Всегда старались отделить подобное, а ещё и тестить блин хз

Звучит, что там в нескольких местах нужен рефакторинг, чтобы улучшить тестируемость. Вы сами видите, что это костыль. Подозреваю что там completable вызывает корутину через runblocking. Есть ещё вариант подменять в тестах планировщик без модификации класса, а извне, через точки расширения rxjava, например в RxJavaPlugins.set*SchedulerHandler.

Вставлю свои 5 копеек. А может все-таки сначала сделать нормально, а потом уже писать тесты? Если вы мигрируете - в чем смысл поставить в БД все функции саспенд, а потом делать костыли? Вас же не заставляют в БД именно все функции делать саспенд. Сделайте одну, которую нормально дальше использовать сможете, потом другую. Если сервис твой работал на Rx без костылей - оставь на rx, пока не придумаешь что с ним делать. Rx и протестировать легко. В крайнем случае, если ты прям контракт БД менять не можешь - можно саспенд функцию преобразовать в Rx c помошью 'org.jetbrains.kotlinx:kotlinx-coroutines-rx3:1.3.9'.