Hey, thanks for looking into this and putting a PR together!

However, I'm a bit concerned that this would add some confusion to the existing DSL: isn't this implementing the behavior we already have for thereturnsMany keyword (seehere)?

Specifically, what you are doing in your example can be written as

every { mock.op() } returnsMany List(3) { _ -> "repeating" }  andThenAnswer { "final" }

@Raibaz, thank you for your comment!
Yes, I often usereturnsMany, and my example doesn't seem appropriate to explain the necessity ofrepeatedly.

As you pointed out,returnsMany is very useful when we want to make a mock return a static value multiple times or predefined values. However, it can't help when we wan to make a mock dynamically generate values multiple times.

Another idea to solve this issue is to addanswersMany. Actually, we made and are using an extension function like the following in our company's project.

infix fun <T> MockKStubScope<T, T>.answersMany(answers: List<Answer<T>>): MockKAdditionalAnswerScope<T, *>

However, this solution has a downside. We need a function like the following to let compiler know the element type of the list given toanswersMany.

fun <T> answerOf(answer: MockKAnswerScope<T, *>.(Call) -> T): Answer<T>

Then code to usereturnsMany will be like the following. I feel like this code isn't cool because of existence ofanswerOf {}.

every { mock.op(any()) } answersMany List(3) { answerOf { generateValue(firstArg()) } } andThen ...

Do you have any idea? Do you feelanswersMany looks better, or is there another better idea?