Mocking case classes and classes without default constructor

[spontagent]

How would I mock case classes?

[cb372]

Currently ScalaMock can only mock classes with a default constructor. If your case class has a default constructor, you should be able to mock it just like a regular class.

Example:

src/main/scala/Foo.scala

case class Foo(a: Int, b: String) {
  def this() = this(1, "asdf") // default constructor
  def something(): Int = 3
}

src/test/scala/FooTest.scala

import org.scalatest._
import org.scalamock.scalatest.MockFactory

class FooTest extends FlatSpec with Matchers with MockFactory {
  "Case class" should "be mocked" in {
    val foo = mock[Foo]
    (foo.something _).expects().returning(5)
    foo.something() should be(5)
  }
}

[pawel-wiejacha]

You don't have to modify your production code by adding a default constructor to case classes.

Example. For case class:

case class CaseClass(integer : Int, string : String) {
  def method() : Integer = integer + 100
}

You can workaround this ScalaMock issue by extending given case class in test code and providing some fake/mock arguments, e.g:

class MockableCaseClass extends CaseClass(0, null)
val m = mock[MockableCaseClass]
(m.method _).expects().returning(5)

We can easily extend MockMaker.initDef method to support mocking classes without a default constructor

[gavares]

This strategy works but requires quite a bit of boilerplate in a project that has a lot of case classes. Being able to mock[MyCaseClass] would be very useful.

[eamonnfaherty-productmadness]

👍

[danmbyrd]

👍 This would be great if we could avoid the boiler plate.

[jeroenvlek]

👍

[michaelahlers]

👍

[tricker]

👍

[gabadi]

+1

[szabba]

👍

[nolanofra]

👍

[psttf]

👍

[fajarmf]

👍

[autodidacticon]

👍

[eyalroth]

👍

[hensg]

👍

[gabadi]

+1

[nolanofra]

👍

[lhohan]

👍

[snaik]

👍

[bkowalik]

I have made PR. Please make review.

[eviatharbl]

+1

[atanana]

+1

[szymon-rd]

+1
I'm totally unable to use it with akka testkit because of it.

[JosephSe]

+1

[greenhost87]

+1

[smrnv]

+1

[burungbangkai]

+1

[akhil]

+1

[xavier-fernandez]

+1

[supramo]

+1

[barkhorn]

just merged some code into master to support constructors with parameters, see PR #163

[ddpaimon]

👍

[bbarker]

I still (in 3.6.0) seem to experience an NPE on mocking a class TableLactationCurves that looks like the following:

class TableLactationCurves(stream: InputStream) extends DataSetXml(stream) with LactationCurves {

The problem is in the DataSetXml constructor:

class DataSetXml(stream: InputStream) {
  protected var dataTypes: mutable.Map[String, DataType] = mutable.Map()
  protected var data: Array[Array[Any]] = null
  private var description: String = null

  try {
    val is = new InputSource()
    is.setCharacterStream(new StringReader(Utils.readStringFromInputStream(stream)))
    loadData(null, is)
  } catch {
    case ex: Exception =>
      throw new RuntimeException(ex)
  }

Of course, i could fix this by not throwing a RuntimeException, I suppose, but that would change application behavior.

Update: As a workaround, I changed this horrid Java-esque (largely translated by IntelliJ) code to have constructors that have lazy val members - this solved the initialization issue for me, though I still think supporting non-lazy initialization makes sense for some cases.

[barkhorn]

Your constructor works on the stream parameter, so NPEs will be expected.
In macro mocks, the constructor actions will be executed.
This might be undesirable, but we can not change this behaviour.
As an alternative, you can try using Proxy Mocks - org.scalamock.scalatest.proxy.MockFactory or org.scalamock.scalatest.MixedMockFactory can create these.
You could also subclass DataSetXml and hardwie the stream parameter to point at a mock/stub.