如何模拟没有返回值的方法是Option [SomeCaseClassDefinedInsideThisClass]的方法的返回

Question

I would expect this test to pass:

import org.scalamock.scalatest.MockFactory
import org.scalatest.{FlatSpec, Matchers}


class FruitImpl {
  case class FruitName(name: String)
  def getFruitName: Option[FruitName] = {
    Some(FruitName("apple"))
  }
}

class FruitSpec extends FlatSpec with Matchers with MockFactory {
  val f = mock[FruitImpl]
  (f.getFruitName _).expects().returning(None)

  behavior of "getFruitName method"

  it should "return None" in {
    f.getFruitName should === (None)
  }
}

But it fails with:

[error] my/path/QuestionTest.scala:13: overriding method getFruitName in class FruitImpl of type => Option[this.FruitName];
[error]  method getFruitName has incompatible type
[error]   val f = mock[FruitImpl]
[error]               ^  

This works, though:

import org.scalamock.scalatest.MockFactory
import org.scalatest.{FlatSpec, Matchers}

case class FruitName(name: String)

class FruitImpl {
  def getFruitName: Option[FruitName] = {
    Some(FruitName("apple"))
  }
}

class FruitSpec extends FlatSpec with Matchers with MockFactory {
  val f = mock[FruitImpl]
  (f.getFruitName _).expects().returning(None)

  behavior of "getFruitName method"

  it should "return None" in {
    f.getFruitName should === (None)
  }
}

The only difference is that the case class FruitName is defined outside of the class FruitImpl. Why does one version of the code fails and the other doesn't? What should one do to fix the error in the first example?

Answer 1

Without looking at the ScalaMock code, I'd say that the mock is not a true derivation of FruitImpl in the OO sense. Its purpose is to allow method interception, so it only deals with the facade . It follows then that the mock actually has no definition of the path dependent type FruitName , and so cannot work with a method signature that depends on it.

This is precisely why it does work when the FruitName definition is moved out of FruitImpl . It now exists independently of the mock, who's method signatures depending on it then work as expected.