Scala testing with type enrichment

Question

I've become attached to type enrichment, for example

object MyImplicits{
  implicit class RichInt(i: Int){
    def complexCalculation: Int = i * 200 
  }
}

Which I use in code like this

object Algorithm{
  def apply(rand: Random) = {
    import MyImplicits._
    rand.nextInt.complexCalculation + 1
  }
}

But how I can isolate and unit test Algorithm now? In particular, I'd like to mock the implemention of complexCalculation, something like this:

class MyAlgorithmTest extends FreeSpec with MockitoSugar{
  import org.mockito.Mockito.when

  "MyApgorithm" {
    "Delegates complex calculation" in {
      val mockRandom = mock[Random]
      when(mockRandom.nextInt()).thenReturn(1)

      // This wouldn't work, but is the kind of thing I'm looking for
      //when(1.complexCalculation).thenReturn(2)
      val expected = 1 * 2 + 1

      val result = MyAlgorithm(mockRandom)
      assert(result === expected)
    }
  }
}

What exactly is your problem? Is it that you want to make sure that your random int object gets converted to the RichInt object during the testing? Or is it that you don't know how to use the assertion for a random value which you do not know? — Samar, Aug 24 '16 at 15:13
I believe @Pengin wants to mock the `complexCalculation` method - but because the creation of the `RichInt` object is made implicitly, there's no way to specify a `when` clause for this `RichInt` object. — virsox, Aug 24 '16 at 15:50

Tim · Accepted Answer · 2016-09-02T15:58:43.537

Implicits enable composition, and when you have composition you typically don't need mocks, because you can substitute implementation for testing. That being said, I'm not a big fan of implicits in this case, just don't see the value they bring. I'd solve it with old school composition (as hinted in my other comment):

trait Calculation {
  def calculation(i: Int): Int
}

trait ComplexCalculation extends Calculation {
  def calculation(i: Int): Int = i * 200
}

trait MyAlgorithm {
  self: Calculation =>

  def apply(rand: Random) = {
    calculation(rand.nextInt) + 1
  }
}

// somewehre in test package

trait MockCalculation extends Calculation {
  def calculation(i: Int): Int = i * 200
}

//test instance
object MyAlgorithm extends MyAlgorithm with MockCalculation

If you insist on using implicits to do composition, you can do this:

trait Computation {
  def compute(i: Int): Int
}

object prod {
  implicit val comp = new Computation {
    def compute(i: Int): Int = i * 200
  }
}

object test {
  implicit val comp = new Computation {
    def compute(i: Int): Int = i + 2
  }
}

object Algorithm {
  def apply(rand: Random)(implicit comp: Computation) = {
    comp.compute(i) + 1
  }
}

// application site
import prod._

Algorithm(scala.util.Random) // will run * 200 computation

//test

import test._

Algorithm(scala.util.Random) // will run + 2 computation

This won't give you a dot syntax for computation though. My gut also goes against this approach because this is a very subtle way of defining behavior and it is easy to make a mistake with what import to bring.

I'm starting to doubt the benefits of type enrichment. Do you see much utility for it, or is it only useful as sugar for fairly simple operations? — Pengin, Sep 02 '16 at 18:26
"Type enrichment" has an official name of "type class" - https://en.wikipedia.org/wiki/Type_class . This is a powerful mechanism to enable 'ad-hoc polymorphism', where you can extend classes that you don't control with new behavior. They also provide a very generic way of defining behavior. Peek at scala collections implementation - in many cases there is an implicit evidence parameter (conventionally called `ev`) that is hinting you that a type class is used to provide a behavior. Look also here: http://stackoverflow.com/questions/5408861/what-are-type-classes-in-scala-useful-for — Tim, Sep 02 '16 at 18:37
and here http://danielwestheide.com/blog/2013/02/06/the-neophytes-guide-to-scala-part-12-type-classes.html — Tim, Sep 02 '16 at 18:37
I don't think type enrichment is the same thing as type classes, but I'm aware they are commonly used together, to make the syntax much nicer. But it's a good answer to my question, i.e. if testing a function which uses a type class, a 'mock' version could be supplied manually rather than letting the compiler just from scope. — Pengin, Sep 02 '16 at 18:46

thirstycrow · Answer 2 · 2016-08-31T05:04:23.570

RichInt.scala

trait RichInt {
  def complexCalculation: Int
}

class RichIntImpl(i: Int) extends RichInt {
  def complexCalculation = i * 200
}

Algorithm.scala

import scala.util.Random

class Algorithm(enrich: Int => RichInt) {
  implicit val _enrich = enrich
  def apply(rand: Random) = {
    rand.nextInt.complexCalculation + 1
  }
}

object Algorithm extends Algorithm(new RichIntImpl(_))

AlgorithmTest.scala

import org.scalatest.FreeSpec
import scala.util.Random
import org.mockito.Mockito._

class AlgorithmTest extends FreeSpec with MockSugar {

  "MyApgorithm should" - {
    "Delegate the complex calculation" in {
      val mockRandom = mock[Random]
      when(mockRandom.nextInt()) thenReturn 1

      val algorithm = new Algorithm(
        enrich = mocking[Int => RichInt] { enrich =>
          when(enrich(1)).thenReturnMocking { richInt =>
            when(richInt.complexCalculation).thenReturn(2)
          }
        }
      )

      val expected = 3

      assert(algorithm(mockRandom) === expected)
    }
  }
}

MockSuger.scala

import org.scalatest.mockito.MockitoSugar
import org.mockito.stubbing.OngoingStubbing

// More sugars to make our tests look better.
trait MockSugar extends MockitoSugar {

  def mocking[T <: AnyRef : Manifest](behavior: T => Unit): T = {
    val m = mock[T]
    behavior(m)
    m
  }

  implicit class RichOngoingStubbing[T <: AnyRef : Manifest](stub: OngoingStubbing[T]) {
    def thenReturnMocking(behavior: T => Unit) = {
      val m = mock[T]
      val s = stub.thenReturn(m)
      behavior(m)
      s
    }
  }
}

All the mock sugar is melting my brain. Can you see a reason why this approach is better than my attempt at an answer using traits? — Pengin, Aug 31 '16 at 18:24
The main issue with the your solution is that it does not take the advantages of the mocking library. It seems ok if you can find a cheap expression to mimic the real calculation for your test case. But for more complex scenarios, you might have to implement some of the mocking utilities by yourself. — thirstycrow, Sep 01 '16 at 02:51
I see that now. Though if this is the best way to do it, it makes me question the elegance of type enrichment - the tests get very hard to read. — Pengin, Sep 01 '16 at 18:35

score 0 · Answer 3 · answered Aug 24 '16 at 15:29

The following uses the scalatest api. The mock tests are running fine and the implicit class conversion is happening ok.

// Implicit.scala in src/main/scala

package implicittesting
import scala.util.Random

object MyImplicits{
  implicit class RichInt(i: Int){
    def complexCalculation: Int = 200*i  // make this complex :)
  }
}

object Algorithm{
  var current = 1
  def apply(rand: Random) = {
    import MyImplicits._
    current = rand.nextInt 
    current.complexCalculation + 100
  }
}


// ImplicitSuite.scala in src/main/test

package implicittesting

import org.scalatest.FunSuite


import org.junit.runner.RunWith
import org.scalatest.junit.JUnitRunner

@RunWith(classOf[JUnitRunner])
class DeleteSuite extends FunSuite {
  import MyImplicits._
  test("algorithm implicit class conversion test") {
    assert(Algorithm(scala.util.Random) == Algorithm.current.complexCalculation + 200)
    println(Algorithm.current)
  }
}

I'd be concerned about the var, but anyway, I was hoping to mock out the 'complexCalculation' logic. — Pengin, Aug 25 '16 at 06:33

score 0 · Answer 4 · answered Aug 24 '16 at 21:11

This is the best I've come up with. I'm willing to admit it seems bonkers.

import org.scalatest.FreeSpec
import org.scalatest.mockito.MockitoSugar
import scala.util.Random

trait MyImplicits {
  implicit class RichInt(i: Int){
    def complexCalculation: Int = complexCalculationImpl(i)
  }

  def complexCalculationImpl(i: Int) = i * 200
}

trait MyAlgorithm extends MyImplicits {
  def apply(rand: Random) = {
    rand.nextInt.complexCalculation + 1
  }
}

//Implementation for use
object MyAlgorithm extends MyAlgorithm

class MyAlgorithmTest extends FreeSpec with MockitoSugar{
  import org.mockito.Mockito.when

  "MyApgorithm should" - {
    "Delegate the complex calculation" in {
      val mockRandom = mock[Random]
      when(mockRandom.nextInt()).thenReturn(1)

      val instance = new MyAlgorithm {
        override def complexCalculationImpl(i: Int) = i * 2
      }

      val expected = 3 // Note we don't expect 201

      assert(instance(mockRandom) === expected)
    }
  }
}

Is there a good reason to use implicits in this case? You have successfully separated complex computation in a module, why don't just mix in different trait implementation in test? — Tim, Sep 02 '16 at 05:06

Scala testing with type enrichment

4 Answers4