VerifyAll with multiple arguments using argWith

[larmic]

Prerequisites

Please answer the following questions for yourself before submitting an issue.

• I am running the latest version
• I checked the documentation and found no answer
• I checked to make sure that this issue has not already been filed

Expected Behavior

The test should pass.

Current Behavior

Trying to verify multiple withArg seems to capture only the last value. Maybe it is the same bug as #352.

Steps to Reproduce

Run following code and it will fail.

class Tweet(val id: Int, val text: String)

interface TweetRepository {

    fun persist(tweet: Tweet)

}

class TweetTest {

    @Test
    internal fun `verify multiple perists`() {
        val repositoryMock = mockk<TweetRepository>(relaxed = true)

        repositoryMock.persist(Tweet(1, "first tweet"))
        repositoryMock.persist(Tweet(2, "second tweet"))

        verifyAll {
            repositoryMock.persist(
                    withArg {
                        assertThat(it.id).isEqualTo(1)
                        assertThat(it.text).isEqualTo("first tweet")
                    })
            repositoryMock.persist(
                    withArg {
                        assertThat(it.id).isEqualTo(2)
                        assertThat(it.text).isEqualTo("second tweet")
                    })
        }
    }
}

Context

Please provide any relevant information about your setup. This is important in case the issue is not reproducible except for under certain conditions.

• MockK version: 1.9.3
• OS: OSX
• Kotlin version: 1.3.60
• JDK version: 11
• JUnit version: 5.5.2
• Type of test: unit test

Failure Logs

org.opentest4j.AssertionFailedError: 
Expecting:
 <2>
to be equal to:
 <1>
but was not.
Expected :1
Actual   :2

[Raibaz]

The bug here seems to be that when the internal matchers see if one of the recorded calls matches the one described by a withArg block, blocks that don't match throw an AssertionError when they try matching with a non-matching invocation.

These errors should be caught when filtering matching invocations and considered as an indicator of the invocation being non-matching, but instead they bubble up and stop the execution of the verification.

I can try putting together a PR for this but it will likely be very ugly.

In the meantime, I think you can achieve the same behavior in your test by using slot() and capture().