New returnsSuccessBy lambda function should pass CallArgs about mokkery HOT 9 OPEN

This and other ...By are analogous to returnsBy, which accepts () -> T on purpose, so it's possible to use property/function reference.

from mokkery.

The two are not mutually exclusive

from mokkery.

I am not sure what you mean. Could you elaborate?

from mokkery.

You can have an overloaded version that is more like calls. To get around this I have defined a function like this:

    infix fun <T> SuspendAnsweringScope<Result<T>>.returnsSuccessBy(
        block: (CallArgs) -> T,
    ) {
        calls {
            try { success(block(it)) } catch (t: Throwable) { failure(t) }
        }
    }

from mokkery.

I don't really like adding this overload:

1. It's ambiguous. To resolve it, you're forced to use a function reference or specify the lambda parameter explicitly.
2. The distinction between returns..By and calls becomes less clear. I see ...By answers as simple utilities for working with properties (especially) or functions without accessing CallArgs.

However, I do see a blind spot in the API - a missing utility that simplifies working with results while still providing full access to the mocked method context. To address this gap, I propose:

public infix fun <T> BlockingAnsweringScope<Result<T>>.callsCatching(block: BlockingCallDefinitionScope<Result<T>>.(CallArgs) -> T) 

public infix fun <T> SuspendAnsweringScope<Result<T>>.callsCatching(block: suspend SuspendCallDefinitionScope<Result<T>>.(CallArgs) -> T)

1. It has stronger name association with calls.
2. Clear intent - the name also relates to runCatching, clearly explaining what's happening.
3. It provides access to other mocked method context operations.

from mokkery.

Works for me. Awaiting this feature. I was trying to implement it myself, but I don't think it is possible outside the library.

from mokkery.

You can temporarily add this:

public infix fun <T> BlockingAnsweringScope<Result<T>>.callsCatching(block: BlockingCallDefinitionScope<Result<T>>.(CallArgs) -> T) {
    calls { runCatching { block(it) } }
}

It's not perfect as the Answer.description returns calls {...} instead of callsCatching {...}. It should not be a problem as this description is used only by debug utils. If it's problematic, implementing custom answers is fully possible (since 2.2.0 it's possible to instantiate BlockingCallDefinitionScope and SuspendCallDefinitionScope).

from mokkery.

You can temporarily add this:

public infix fun <T> BlockingAnsweringScope<Result<T>>.callsCatching(block: BlockingCallDefinitionScope<Result<T>>.(CallArgs) -> T) {
    calls { runCatching { block(it) } }
}

It's not perfect as the Answer.description returns calls {...} instead of callsCatching {...}. It should not be a problem as this description is used only by debug utils. If it's problematic, implementing custom answers is fully possible (since 2.2.0 it's possible to instantiate BlockingCallDefinitionScope and SuspendCallDefinitionScope).

That doesn't quite work as you want block to be of type BlockingCallDefinitionScope<T>.(CallArgs) -> T not BlockingCallDefinitionScope<Result<T>>.(CallArgs) -> T, i..e. it shoud return T not Result<T>

from mokkery.

It is correct. The T in CallDefinitionScope<T> indicates the return type of a mocked method, so it being Result<T> is correct. The only inconvenience is that callOriginal and callSuper are returning Result that requires unwrapping.

Also, it got me thinking about the other issue. callOriginal and callSuper might fail and probably MokkeryRuntimeExceptions should not be caught with callsCatching

from mokkery.