How do you properly mock an Either<> response? I have a function where I want to test the Left...

# arrow

[Stian N]

How do you properly mock an Either<> response? I have a function where I want to test the Left case, but using mockK this way gives me a Right(b=Left(a....))

every { someFunction(any()) } answers { Either.left("Go left")) }

[simon.vergauwen]

That’s weird. I am not familiar with mockK but that looks correct.

I don’t think the issue lies with this line of code

[Satyam Agarwal]

This is 💔 . When you do that, it means that you are not testing the logic of converting your side-effect and result into Either, would be rather nice to mock (if need be) the result of the real method that throws or gives a value.

[Satyam Agarwal]

Also you should really try out DockerTestContainers to mock your external services. Since 7 applications, I have stopped using any mock unit testing libraries.

[Stian N]

I'm doing that in a different test. In this test I just want to verify how this class handles Left

[simon.vergauwen]

If you can give a more complete example I might be able to provide more help 🙂

[Stian N]

@simon.vergauwen You are correct, the error is somewhere else. I just did a simple test where this line worked as expected.

[Stian N]

@Satyam Agarwal Do you do TDD or do you only write e2e tests?

[Satyam Agarwal]

I do TDD and e2e, most of my apps are web apps, so here is how i follow :
1. No tests for repositories.
2. Test thoroughly the service layer, by adding functional tests for all possible scenarios.
Also, accept the fact that there are scenarios which cannot be tested with functional tests, for example database connection failure (and its messy anyway to test it with mocks)
3. Write functional tests for router with one possible failure of all the services you are calling in the router,
4. one happy path.

And that pretty much brings my average coverage to ~80-85%

[Satyam Agarwal]

I am happy with this 🙂 I have accepted that coverage tending to 100% makes the project unnecessarily verbose

[Stian N]

Yeah, 100% coverage doesn't make sense.

[Stian N]

@simon.vergauwen I think the problem is because of a Try { } statement in the mocked function.