Is there a way to generate any() objects for metho...

# announcements

[Sarah Gross]

Is there a way to generate any() objects for method params, so I don't end up with code that has a long list of any() in my test? It's not a vararg method, but maybe there's a way to use repeat or unpacking syntax?

_whenever_(myMethod(
_any_(), _any_(),_any_(), _any_(), _any_(), _any_(), _any_(), _any_())
).thenReturn

[Joel]

Indirect answer: I usually switch to a config pattern when I get this many args to a function.

class BuilderDsl {
  var foo: Int
  var bar: Int
}

fun doSomething(config: BuilderDsl.() -> Unit): Int {
  return BuilderDsl().apply(config).let { it.foo + it.bar }
}

Then you only have to mock the config lambda.

[Joel]

Obviously there are exceptions but it's a nice pattern to have in the toolbox.

[Sarah Gross]

thanks Joel

[Sarah Gross]

it's an interface call, so not sure how this would apply here

[Tobias Berger]

To answer the actual question: the only way to do that would be reflection which just makes it weirder than it already is.
Anyways, I'd advise against it for different reasons.
• I like to make my mocks as specific as possible/sensible and tend to mock only the calls I actually expect to accur. That way I worry less about code that "accidentally works".
• The other thing is that many coders would consider a method with so many arguments a code smell. At least most clean code guidelines would advise against it. If the interface is defined by you and not part of an external lib, you could wrap parameters in an additional class. I guess it depends on the case if that's worth the effort.
On a completely different note: assuming you wrote the interface yourself, this is actually a good example of one benefit of test-driven development. If you start with writing the test, you will usually end up with code that's more easily testable.

[Joel]

Reflection to make tests work sounds pretty complex. You'd probably end up writing tests for your test.

[Joel]

@Sarah Gross another tip - I've found mockk to be easier to use than mockito when it comes to Kotlin code. There may be something of value in there.

[Sarah Gross]

noted thanks