Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: mock that return set of Mocks fails #221

Closed
alaxwork opened this issue Jan 10, 2019 · 5 comments
Closed

Bug: mock that return set of Mocks fails #221

alaxwork opened this issue Jan 10, 2019 · 5 comments
Labels
bug fixed fixed in master

Comments

@alaxwork
Copy link

Description

I trying to mock the following interfaces:

interface Foo {
    fun getTasks(): Set<Task>
}

interface Task {
    fun doIt()
}

Test example:

@Test
fun prepare() {
    val foo = mockk<Foo>()
    every { foo.getTasks() } returns setOf(mockk(), mockk())
}

Special for the test that mock returns set of mocks again. HashMap invokes then hashCode method of the mock object.

Expected Behavior

The test should pass

Current Behavior

The test fails

Failure Information (for bugs)

Stack trace

io.mockk.MockKException: Bad recording sequence. Please finalize every { ... } block with returns/answers/just Runs

	at io.mockk.impl.recording.states.CallRecordingState.cancelAndThrowBadRecordingState(CallRecordingState.kt:30)
	at io.mockk.impl.recording.states.CallRecordingState.call(CallRecordingState.kt:12)
	at io.mockk.impl.recording.CommonCallRecorder.call(CommonCallRecorder.kt:54)
	at io.mockk.impl.stub.MockKStub.handleInvocation(MockKStub.kt:272)
	at io.mockk.impl.instantiation.JvmMockFactoryHelper$mockHandler$1.invocation(JvmMockFactoryHelper.kt:25)
	at io.mockk.proxy.jvm.advice.Interceptor.call(Interceptor.kt:20)
	at io.mockk.proxy.jvm.advice.BaseAdvice.handle(BaseAdvice.kt:42)
	at io.mockk.proxy.jvm.advice.jvm.JvmMockKProxyInterceptor.intercept(JvmMockKProxyInterceptor.java:31)
	at Task$Subclass2.hashCode(Unknown Source)
	at java.util.HashMap.hash(HashMap.java:338)
	at java.util.HashMap.put(HashMap.java:611)
	at java.util.HashSet.add(HashSet.java:219)
	at kotlin.collections.ArraysKt___ArraysKt.toCollection(_Arrays.kt:7522)
	at kotlin.collections.ArraysKt___ArraysKt.toSet(_Arrays.kt:7857)
	at kotlin.collections.SetsKt__SetsKt.setOf(Sets.kt:42)
	at Test.prepare(Test.kt:18)

Minimal reproducible code (the gist of this issue)

import io.mockk.every
import io.mockk.mockk
import org.junit.jupiter.api.Test

interface Foo {
    fun getTasks(): Set<Task>
}

interface Task {
    fun doIt()
}

internal class Test {

    @Test
    fun prepare() {
        val foo = mockk<Foo>()
        every { foo.getTasks() } returns setOf(mockk(), mockk())
    }
}
@oleksiyp
Copy link
Collaborator

Looks seriius, thanks for the report

@jcornaz
Copy link

jcornaz commented Jan 14, 2019

Isn't the same issue as #201 ?

Currently MockK doesn't support creating mocks during stubbing.

The following version passes, since the mocks are created before the stubbing.

@Test
fun prepare() {
    val foo = mockk<Foo>()
    val set = setOf(mockk<Task>(), mockk<Task>())
    every { foo.getTasks() } returns set
}

P.S: While waiting for #201, another alternative is to use answers instead of returns:

@Test
fun prepare() {
    val foo = mockk<Foo>()
    every { foo.getTasks() } answers { setOf(mockk(), mockk()) }
}

@oleksiyp
Copy link
Collaborator

oleksiyp commented Jan 14, 2019

@jcornaz missed this point. It might be, but I have doubts. There we have stubbing inside of unfinished stubbing and here just set of two mockks. Require a check, will check later

oleksiyp added a commit that referenced this issue Feb 9, 2019
@oleksiyp oleksiyp added bug fixed fixed in master labels Feb 9, 2019
@oleksiyp oleksiyp changed the title Mock that return set of Mocks fails Bug: mock that return set of Mocks fails Feb 9, 2019
@oleksiyp
Copy link
Collaborator

Released 1.9.1. Please try it out and close the ticket if everything is fine

@alaxwork
Copy link
Author

I've tested. It's working as expected. Thank you.

Endhuine pushed a commit to Endhuine/mockk that referenced this issue Jun 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug fixed fixed in master
Projects
None yet
Development

No branches or pull requests

3 participants