ScalaMock 3.0 problems with polymorphic types about scalamock HOT 21 CLOSED

More generally, it looks like this can be mocked...

trait TestTrait {
  def foo[T]: T
}

... and this can't

interface JavaInterface {
  <T> T foo();
}

This is my first exposure to macros, but the resulting Expr's look the same via showRaw? Not sure how to further debug this.

from scalamock.

Very many thanks for the report. I've verified that I can reproduce the problem.

I'll investigate and get back to you as soon as I have anything to report.

from scalamock.

Hi I have the same issue when trying to mock a Trait with type parameters. The folks at Scala channel gave me the hint that this is related to macros.

from scalamock.

@magnusart - you mean you're seeing it when trying to mock something written in Scala (not Java)? I'd be very grateful if you could make an example available to me.

from scalamock.

Hi, I'm travelling right now but I'll do my best.

I used the GenTraversable trait from ScalaIO with String as type parameter.

val m = mock[GenTraversable[String]]

It seemed to me that any trait with type parameter failed. I also tried with Traversable[String]

I was using ScalaTest 2 M5 I think. Hope that helps otherwise I'll give you an examples tomorrow.

from scalamock.

@magnusart thanks - that got me far enough to be able to reproduce something (although not exactly the same error as @spiffxp was getting). I get "Parameter type in structural refinement may not refer to an abstract type defined outside that refinement" - are you seeing the same symptoms?

FYI, you might find this conversation on scala-user interesting:

https://groups.google.com/d/topic/scala-user/66jbw3gS9KY/discussion

It looks like I underestimated the complexity of building method signatures (and got lucky with the test cases I tried). I'm working on it, but it doesn't look like there's a quick fix I'm afraid.

from scalamock.

Paul: yes that is the error I'm getting. Sorry for the confusion, I should have read the thread more closely. I thought it was the same issue at first.

I had a quick look at the discussion (and the sources) and I think you're out of my depth, at least currently, when looking at macros and the type system in detail.

I'm not sure if it helps much but there are some knowledgeable and helpful people around in the Scala channel on freenode.

from scalamock.

@magnusart Actually, although the error is different, the underlying cause is the same I think.

I'm in touch with Eugene, who is the architect of macros in Scala, so I should be able to figure it out with his help :-)

Very many thanks once again (both of you) for your help with bringing this to my attention.

from scalamock.

Given that this is a slightly deeper problem than anticipated, is it possible at all to cross-compile ScalaMock 2.x to work with Scala 2.10? I attempted briefly, but the sbt project is way out of my league

from scalamock.

I'm not sure that it's worth trying to get the compiler plugin used by ScalaMock2 to compile against 2.10. Firstly because the internals of the compiler have changed somewhat, but mainly because the compiler plugin has similar (not the same, but similar) issues.

I hoped that moving to macros instead of a compiler plugin would be a way to avoid those issues - if you've been following the conversation on scala-user, you'll be aware that hope turned out to be in vain.

However, it should be possible to get proxy mocks up and running in 2.10 easily enough. They're not typesafe, but they do work. Would that be enough for your purposes?

from scalamock.

Yeah I think proxy mocks would be useful at this point

from scalamock.

Agreed. Working on it - shouldn't take too long.

from scalamock.

I've just checked in updates to reinstate proxy mocks, and pushed 3.1-SNAPSHOT to SonaType. I'd be grateful if you could try them out and let me know if you experience any problems.

I've not yet updated the documentation, but there are examples of how to use them here: https://github.com/paulbutcher/ScalaMock/tree/master/examples/src/test/scala/com/example/proxy

from scalamock.

Thanks for the quick work, unfortunately I'm still stuck on a few quirks. I'll try to better isolate these into test cases later. In brief:

• sbt started warning about a possible conflict with org.scala:2.10.0 unless I moved the ScalaMock dependency out of test scope
• IntelliJ's syntax highlighting became thoroughly confused (I'm slightly behind here, I'll try bumping to latest versions of the IDE and scala plugin to see if that helps)
• I had an invocation of onCall refuse to compile because Product => Any was expected, but (Foo, Bar) => Unit was found
• A suite-scoped mock configured with different expectations in two different tests was complaining about an unexpected call if I ran both tests together, but was happy with each test being run individually

from scalamock.

Yikes - that's quite a laundry list.

If you can characterise them better, I'm sure we can work through them. Thanks for taking the time to help.

from scalamock.

The last of these (suite-scoped mock) is probably the same issue as #25, just different symptoms.

from scalamock.

• The sbt issue turned out to be be ScalaTest 1.9.1 sneaking in as a transitive dependency, even though it was getting evicted by 2.0.M5b. So, nevermind there.
• Syntax highlighting is probably an IntelliJ issue. Running 12.0.2 w/ the latest stable Scala plugin I was able to narrow it down to being unable to resolve the correct implementation of mock, even though it can run the tests just fine. If you want to see for yourself: https://gist.github.com/4593075
• Test case for onCall: https://gist.github.com/4593095
• Test case for suite-scoped mock: https://gist.github.com/4593110 (agreed that this is a different facet of the same issue)

from scalamock.

I was looking for the proxy mocks as well, but I don't see the 3.1-SNAPSHOT on sonatype.

I'm using the following to try and import the 3.1 release.

"org.scalamock" %% "scalamock-scalatest-support" % " 3.1-SNAPSHOT" % "test"

Any guidance on how I might get proxy mocks working?

from scalamock.

@coltfred - you need to let sbt know to look at the snapshots repo:

resolvers += Resolver.sonatypeRepo("snapshots")

from scalamock.

I'm working on this issue, namely:

interface JavaInterface { <T> T foo(); }

trait ScalaInterface {  def foo[T]: T }
mock[ScalaInterface] // ok
mock[JavaInterface] /* fails to compile with:
 found   : T(in value mock$foo$0 )
 required: T(in method foo)
*/

showRaw shows no difference in generated code, but running Scala compiler under debugger with enabled macro and reflection debugging led me to following difference in generated code:

// ScalaInterface
<method> override def foo[T](a: scala.this.Int): T = $anon.this.mock$foo$0.apply(a);
<triedcooking> private[this] val mock$foo$0 : scalamock.this.MockFunction1[scala.this.Int,T] = new scalamock.this.MockFunction1[scala.this.Int,T].<init>(MockTest.this._factory, scala.Symbol.apply("foo"))(scalamock.this.Defaultable.default[T]);

// JavaInterface
<method> override def foo[T](x$1: scala.this.Int): T = $anon.this.mock$foo$0.apply(x$1);
<triedcooking> private[this] val mock$foo$0 : scalamock.this.MockFunction1[scala.this.Int,T] forSome { type T } = new scalamock.this.MockFunction1[scala.this.Int,T].<init>(MockTest.this._factory, scala.Symbol.apply("foo"))(scalamock.this.Defaultable.default[T]);

It seems that for some reason, using ValDef type deduction (i.e. tpt=TypeTree()) creates MockFunction1 parametrized with existential type.

This can be easily fixed by using: AppliedTypeTree(Ident(clazz.typeSymbol), types) instead of TypeTree() in ValDef created by MockImpl.mockMethod(), however this approach breaks repeated params handling.

from scalamock.

I fixed this issue on https://github.com/pawel-wiejacha/ScalaMock/tree/master-2.10:

commit 2ea920edc692032a1a396b226de391d8483b827b
    Backport of 'Removed implict T* => Seq[T] conversions as they are handled explicilty' from master-2.11

commit bc103861096e2d80003f244c7a0bc28b808f2631
    Backport of 'Fixed issue #24: mocking Java polymorphic methods' from master-2.11

from scalamock.