fmonniot
commented
2 weeks ago Hello there,
Ooh, that's a fun one. Indeed I never had to mock a method with a default value and so it's not implemented. It's interesting to see how Scala hack around the fact that default values do not exist in Java land.
Even more interesting is how this is used by the compiler. If we print the AST of a trait with a default method (for example with PrintAst[TestDefaultParameters]) we see the following:
@scala.annotation.internal.SourceFile("core/src/test/scala/fixtures/TestDefaultParameters.scala") trait TestDefaultParameters() extends java.lang.Object {
def foo(bar: scala.Int): scala.Predef.String
def foo$default$1: scala.Int @scala.annotation.unchecked.uncheckedVariance = 9
}So it seems like the compilere store the default parameters in methods alongside the main one and use a methodName$default$position scheme to do so. We can also see how the compiler uses those synthetic methods with
PrintAst {
val t = new TestDefaultParameters {}
t.foo()
}which prints
{
val t: fixtures.TestDefaultParameters = {
final class $anon() extends fixtures.TestDefaultParameters
(new $anon(): fixtures.TestDefaultParameters)
}
t.foo(t.foo$default$1)
}So a priori detecting if a method is generated by the compiler or not should be enough. In those cases we simply ignore them and let the compiler do its magic. Lemme see if I can find something.
NPCRUS
Cheers @fmonniot. First of all - thank you for great work on this library, it was a bliss to find it. Now to the point: I think mocking methods with default parameters are currently broken with following error:
value mocks cannot be accessed as a member of (Service2Mock.this : Service2Mock) from class Service2. [error] | private value mocks can only be accessed from class Service2Mock.I've made a smallest reproducible example of this issue:here is the debugging output together with error:
If you don't have time, let me know - I'm willing to take a stab at this issue myself