• Add support for polymorphic (type parameterised) methods
• Add support for curried methods
• Fix String constants in Java classes
• Fix unmocked operators

ScalaMock is a native Scala mocking framework which, as well as traits (interfaces) and functions, can also mock:

• Classes
• Singleton and companion objects (static methods)
• Object creation (constructor invocation)
• Polymorphic (type parameterised) methods
• Classes with private constructors
• Final classes and classes with final methods
• Operators (methods with symbolic names)
• Overloaded methods

• Classes
• Singleton and companion objects (static methods)
• Object creation (constructor invocation)
• Classes with private constructors
• Final classes and classes with final methods
• Operators (methods with symbolic names)
• Overloaded methods

This post describes how to setup a project that uses ScalaMock in conjunction with ScalaTest and sbt 0.11. The sample code described in this article is available on GitHub.

Note: If you only want to mock functions and traits (interfaces), you can use ScalaMock’s proxy mocks by simply linking with the .jar file – no need to use the compiler plugin or sbt plugin described below.

The example assumes that we’re writing code to control a mechanical turtle, similar to that used by Logo programs. Mocking is useful in this kind of situation because we might want to create tests that function even if we don’t have the hardware to hand, which run more quickly than would be the case if we ran on real hardware, and where we can use mocks to simulate errors or other situations difficult to reproduce on demand.

Getting started

1. Create a root directory for your project:

   $ mkdir myproject

2. ScalaMock uses a compiler plugin to generate code. There’s an sbt plugin that makes setting this up easy. Add this plugin to your project by creating project/project/Build.scala containing:

   import sbt._
   object PluginDef extends Build {
     override lazy val projects = Seq(root)
     lazy val root = Project("plugins", file(".")) dependsOn(scalamockPlugin)
     lazy val scalamockPlugin = uri("git://github.com/paulbutcher/scalamock-sbt-plugin")
   }

3. Create project/Build.scala containing:

   import sbt._
   import Keys._
   import ScalaMockPlugin._
    
   object MyBuild extends Build {
    
     override lazy val settings = super.settings ++ Seq(
       organization := "com.example",
       version := "1.0",
       scalaVersion := "2.9.1",
    
       resolvers += ScalaToolsSnapshots,
       libraryDependencies += "org.scalamock" %% "scalamock-scalatest-support" % "2.0-SNAPSHOT",
       autoCompilerPlugins := true,
       addCompilerPlugin("org.scalamock" %% "scalamock-compiler-plugin" % "2.0-SNAPSHOT"))
    
     lazy val myproject = Project("MyProject", file(".")) settings(generateMocksSettings: _*) configs(Mock)
   }

Simple mocking

4. Now we’ve got a project, we need some code to test. Let’s start with a simple trait representing a turtle. Create src/main/scala/Turtle.scala containing:

   package com.example
    
   trait Turtle {
     def penDown()
     def penUp()
     def forward(distance: Double)
     def turn(angle: Double)
     def getPosition: (Double, Double)
     def getAngle: Double
   }

5. The turtle API is not very convenient, we have no way to move to a specific position, instead we need to work out how to get from where we are now to where we want to get by calculating angles and distances. Here’s some code that draws a line from a specific point to another by doing exactly that.

   Create src/main/scala/Controller.scala containing:

   package com.example
    
   import scala.math.{atan2, sqrt}
    
   class Controller(turtle: Turtle) {
    
     def drawLine(start: (Double, Double), end: (Double, Double)) {
       moveTo(start)
    
       val initialAngle = turtle.getAngle
       val deltaPos = delta(start, end)
    
       turtle.turn(angle(deltaPos) - initialAngle)
       turtle.penDown
       turtle.forward(distance(deltaPos))
     }
    
     def delta(pos1: (Double, Double), pos2: (Double, Double)) = 
       (pos2._1 - pos1._1, pos2._2 - pos1._2)
    
     def distance(delta: (Double, Double)) = 
       sqrt(delta._1 * delta._1 + delta._2 * delta._2)
    
     def angle(delta: (Double, Double)) = 
       atan2(delta._2, delta._1)
    
     def moveTo(pos: (Double, Double)) {
       val initialPos = turtle.getPosition
       val initialAngle = turtle.getAngle
    
       val deltaPos = delta(initialPos, pos)
    
       turtle.penUp
       turtle.turn(angle(deltaPos) - initialAngle)
       turtle.forward(distance(deltaPos))
     }
   }

6. In order to create mock turtles, we need to tell ScalaMock to generate the appropriate code by using the @mock annotation. Create src/generate-mocks/scala/GenerateMocks.scala containing:

   package com.example
    
   import org.scalamock.annotation.mock
    
   @mock[Turtle]
   class Dummy

7. We can now write a test. We’ll create a mock turtle that pretends to start at the origin (0, 0) and verifies that if we draw a line from (1, 1) to (2, 1) it performs the correct sequence of turns and movements.

   

   Create src/test/scala/ControllerTest.scala containing:

   package com.example
    
   import org.scalatest.FunSuite
   import org.scalamock.scalatest.MockFactory
   import org.scalamock.generated.GeneratedMockFactory
   import scala.math.{Pi, sqrt}
    
   class ControllerTest extends FunSuite with MockFactory with GeneratedMockFactory {
    
     test("draw line") {
       val mockTurtle = mock[Turtle]
       val controller = new Controller(mockTurtle)
    
       inSequence {
         inAnyOrder {
           mockTurtle.expects.penUp
           mockTurtle.expects.getPosition returning (0.0, 0.0)
           mockTurtle.expects.getAngle returning 0.0
         }
         mockTurtle.expects.turn(~(Pi / 4))
         mockTurtle.expects.forward(~sqrt(2.0))
         mockTurtle.expects.getAngle returning Pi / 4
         mockTurtle.expects.turn(~(-Pi / 4))
         mockTurtle.expects.penDown
         mockTurtle.expects.forward(1.0)
       }
    
       controller.drawLine((1.0, 1.0), (2.0, 1.0))
     }
   }

   This should (hopefully!) be self-explanatory, with one possible exception. The tilde (~) operator represents an epsilon match, useful for taking account of rounding errors when dealing with floating-point values.

8. Generate mocks with generate-mocks and then run the tests with test:

   $ sbt
   > generate-mocks
   [log generatemocks] Creating mock for: trait Turtle
   > test
   [info] ControllerTest:
   [info] - draw line
   [info] Passed: : Total 1, Failed 0, Errors 0, Passed 1, Skipped 0

Getting clever: Constructors and singleton objects

9. Turtles use ink. Let’s define a singleton object that keeps track of how much we’ve used.

   Create src/main/scala/InkReservoir.scala containing:

   package com.example
    
   object InkReservoir {
    
     def use(r: Double, g: Double, b: Double) {
       red -= r
       green -= g
       blue -= b
     }
    
     private var red = 10.0
     private var green = 10.0
     private var blue = 10.0
   }

10. And now let’s create a concrete implementation of our Turtle trait, which adds the ability to define a pen colour, together with a factory method implemented in its companion object.

    Create src/main/scala/ColouredTurtle.scala containing:

    package com.example
     
    import scala.math.{cos, sin}
     
    class ColouredTurtle(r: Double, g: Double, b: Double) extends Turtle {
      def penDown() { penIsDown = true }
      def penUp() { penIsDown = false }
      def turn(angle: Double) { theta += angle}
      def getPosition: (Double, Double) = (x, y)
      def getAngle: Double = theta
      def forward(d: Double) { 
        x += sin(theta) * d
        y += cos(theta) * d
        if (penIsDown)
          InkReservoir.use(r * d, g * d, b * d)
      }
     
      private var penIsDown = false
      private var x = 0.0
      private var y = 0.0
      private var theta = 0.0
    }
     
    object ColouredTurtle {
     
      def apply(colour: Symbol) = {
        val (r, g, b) = colourMap(colour)
        new ColouredTurtle(r, g, b)
      }
     
      private val colourMap = Map('red -> (1.0, 0.0, 0.0), 'green -> (0.0, 1.0, 0.0), 'blue -> (0.0, 0.0, 1.0))
    }

11. To mock ColouredTurtle, first we need to add another @mock annotation to GenerateMocks.scala:

    @mock[ColouredTurtle]

12. We can now write a test to verify that our factory method works.

    Create src/test/scala/ColouredTurtleTest.scala:

    package com.example
     
    import org.scalatest.FunSuite
    import org.scalamock.scalatest.MockFactory
    import org.scalamock.generated.GeneratedMockFactory
     
    class ColouredTurtleTest extends FunSuite with MockFactory with GeneratedMockFactory {
     
      test("coloured turtles") {
        val m1 = mock[ColouredTurtle]
        val m2 = mock[ColouredTurtle]
     
        m1.expects.newInstance(1.0, 0.0, 0.0)
        m2.expects.newInstance(0.0, 1.0, 0.0)
        m2.expects.forward(3.0)
     
        val t1 = ColouredTurtle('red)
        val t2 = ColouredTurtle('green)
        t2.forward(3.0)
      }
    }

13. Run the tests again (don’t forget to run generate-mocks first) to see:

    [info] ColouredTurtleTest:
    [info] - coloured turtles
    [info] ControllerTest:
    [info] - draw line
    [info] Passed: : Total 2, Failed 0, Errors 0, Passed 2, Skipped 0

14. Finally, we can add a test to verify that we’re keeping track of ink correctly. Let ScalaMock know that we’ll be mocking InkReservoir by adding a @mockObject annotation:

    @mockObject(InkReservoir)

    And add a test to ColouredTurtleTest.scala:

      test("ink reservoir") {
        val m = mockObject(InkReservoir)
     
        m.expects.use(0.0, 3.0, 0.0)
     
        val t = ColouredTurtle('green)
        t.penDown
        t.forward(3.0)
      }

[info] ControllerTest:
[info] - draw line
[info] ColouredTurtleTest:
[info] - coloured turtles
[info] - ink reservoir
[info] Passed: : Total 3, Failed 0, Errors 0, Passed 3, Skipped 0

1. Install sbt 0.10.1
2. Create the root directory for your project:

   $ mkdir aproject

3. Create a settings file in this directory called build.sbt containing:

   name := "A Project"
    
   version := "0.1"
    
   scalaVersion := "2.9.1"
    
   libraryDependencies ++= Seq(
     "org.scalatest" %% "scalatest" % "1.6.1" % "test"
   )

4. Create src/main/scala/Widget.scala containing:

   package com.example
    
   class Widget {
     def colour = "Blue"
     def disposition = "Awesome"
   }

5. Create src/test/scala/WidgetTest.scala containing:

   package com.example.test
    
   import org.scalatest.FunSuite
   import com.example.Widget
    
   class WidgetTest extends FunSuite {
    
     test("colour") {
       expect("Blue") { new Widget().colour }
     }
    
     test("disposition") {
       expect("Awesome") { new Widget().disposition }
     }
   }

6. Run your tests with sbt test. You should see:

   [info] WidgetTest:
   [info] - colour
   [info] - disposition
   [info] Passed: : Total 2, Failed 0, Errors 0, Passed 2, Skipped 0

7. Create src/main/scala/Main.scala containing:

   package com.example
    
   object Main {
     def main(args: Array[String]) {
       val w = new Widget()
       println("My new widget is "+ w.colour)
     }
   }

8. Run your program with sbt run. You should see:

   [info] Running com.example.Main 
   My new widget is Blue

Over the last few weeks, I’ve been working on major enhancements for Borachio (my native mocking library for Scala) to add facilities similar to those provided by PowerMock for Java. As well as interfaces and functions, it can now mock:

• Classes
• Final classes and classes with final methods
• Classes with private constructors
• Singleton (companion) objects
• Object creation (i.e. new)

And, as an extra bonus, mocks are now typesafe .

It’s not completely finished yet, but it is close enough that it’s worth soliciting feedback. The code is available on GitHub and a snapshot is available on scala-tools.

Warning: Although this is getting close to “done”, the details may change slightly before final release.

So what does this look like in action? I’m going to demonstrate with a slightly modified version of Martin Fowler’s “warehouse” example from Mocks Aren’t Stubs. This example is available on GitHub. First, here’s a Warehouse object (a Scala singleton object):

object Warehouse {
  val products = Map(("Talisker" -> 5), ("Lagavulin" -> 2))
 
  def hasInventory(product: String, quantity: Int) = 
    inStock(product) >= quantity
 
  def remove(product: String, quantity: Int) = 
    products += (product -> (inStock(product) - quantity))
 
  def inStock(product: String) = products.getOrElse(product, 0)
}

And here’s an Order class that removes things from the warehouse:

class Order(product: String, quantity: Int) {
  var filled = false
 
  def fill() {
    if (Warehouse.hasInventory(product, quantity)) {
      Warehouse.remove(product, quantity)
      filled = true
    }
  }
}
 
object Order {
  def apply(product: String, quantity: Int) = 
    new Order(product, quantity)
 
  def largestPossible(product: String) = {
    val quantity = Warehouse.inStock(product)
    new Order(product, quantity)
  }
}

First, let’s see how we can go about testing the Order class by mocking the Warehouse object:

test("Enough stock") {
  val mockWarehouse = mockObject(Warehouse)
 
  mockWarehouse.expects.hasInventory("Talisker", 50) returning true
  mockWarehouse.expects.remove("Talisker", 50)
 
  val order = Order("Talisker", 50)
  order.fill
 
  assert(order.filled)
}

The “magic” happens in the mockObject call:

  val mockWarehouse = mockObject(Warehouse)

This returns a mock version of the Warehouse object upon which expectations can be set. From that point onwards, the code should be pretty self-explanatory.

Another example, this time of mocking object creation:

test("Order everything") {
  val mockWarehouse = mockObject(Warehouse)
  val mockOrder = mock[Order]
 
  mockWarehouse.expects.inStock("Laphroig") returning 10
  mockOrder.expects.newInstance("Laphroig", 10)
 
  Order.largestPossible("Laphroig")
}

This uses two mock objects, one representing the Warehouse object and one representing an (as yet uncreated) instance of the Order class:

  val mockWarehouse = mockObject(Warehouse)
  val mockOrder = mock[Order]

The interesting line is this one:

  mockOrder.expects.newInstance("Laphroig", 10)

Which sets an expectation that a new instance of the Order class will be created with constructor arguments ("Laphroig", 10).

Building

Most of the cleverness happens within a Scala compiler plugin. Compiling tests that use mocks requires three steps:

1. Compile the code you want to test as normal.
2. Compile this code again with the Borachio compiler plugin enabled. The plugin will generate mock source code for any classes and objects mentioned in @mock @mockObject annotations.
3. Compile this code together with your test code

These steps have all been collected into an sbt plugin, so all you need to do is mix the GenerateMocks trait into your project definition and everything else should happen automagically.

Under the hood

Given the Order class in our example above, the compiler plugin generates two different classes, one with the same name (i.e. Order) and one called Mock$Order. Here’s (a simplified version of) what they look like:

class Order(dummy: MockConstructorDummy) extends Mock$Order {
 
  def fill(): Unit = mock$0()
  def this(product: String, quantity: Int) = {
    this(new MockConstructorDummy)
    mock$1(product, quantity)
  }
 
  lazy val mock$0 = new MockFunction0[Unit]
  lazy val mock$1 = new MockConstructor2[String, Int, Order]
}
 
trait Mock$Order {
 
  val expects = new {
    def fill() = mock$0.expects()
    def newInstance(product: String, quantity: Int) = 
      mock$1.expects(product, quantity)
 
    lazy val mock$0 = // reference to mock$0 in Order
    lazy val mock$1 = // reference to mock$1 in Order
  }
}

Borachio then uses a custom class loader to ensure that, when the code being tested tries to load the Order class, it gets the generated version above (calls get forwarded to the “real” Order class if mocking isn’t in force).

To do

I hope that this code is complete enough to be useful. Certainly it’s complete enough that I’d welcome feedback on anything that doesn’t work or could be done better. The things that still need doing are:

• Android and JUnit3 integration
• Support for mocking private constructors and methods
• Forwarding to non-mock singleton functionality (this is in place for classes, not yet for singleton objects)
• Static method (Java) support
• Support for type-parameterised methods

Borachio, my native mocking library for Scala, works well enough but has a couple of annoying limitations:

• It can only mock functions and traits (interfaces). No support for classes, companion objects, constructors, etc. etc. etc.
• It’s not typesafe.

I’ve been working to address those limitations and, although I’m far from done, I’ve made enough progress to be worth reporting.

Warning: The code described here is experimental and very likely to change. Use at your own risk, and don’t be surprised if things break in the future.

This experimental version of Borachio (the code is in the typesafemocks branch and a compiled snapshot is available here) uses a Scala compiler plugin to generate typesafe mock objects. These mock objects can extend traits or classes.

Unfortunately, current limitations of the Scala compiler plugin architecture mean that it’s effectively impossible to generate methods within a compiler plugin (see this discussion to understand why). So the Borachio plugin instead requires two passes – one pass to generate the source and then a second pass to compile it.

There’s an example of its use (an updated version of the Turtle example) available on GitHub.

The key class in this example is Turtle:

class Turtle {
  def penUp() { ... }
  def penDown() { ... }
  def forward(distance: Double) { ... }
  def turn(angle: Double) { ... }
  def getAngle = { ... }
  def getPosition = { ... }
}

In the first pass, the compiler is called with the -P:borachio:generatemocks argument. This causes the plugin to look for @mock annotations to determine which classes it needs to generate mocks for. Here’s how we specify that we want to create mock turtles:

@mock(classOf[Turtle])
class Dummy

And here’s what the plugin generates as a result:

class MockTurtle(factory: com.borachio.AbstractMockFactory) extends com.example.Turtle {
  override def getPosition = mock$getPosition()
  override def getAngle = mock$getAngle()
  override def turn(angle: Double) = mock$turn(angle)
  override def forward(distance: Double) = mock$forward(distance)
  override def penDown() = mock$penDown()
  override def penUp() = mock$penUp()
 
  val expects = new {
    def getPosition: com.borachio.TypeSafeExpectation[(Double, Double)] = mock$getPosition.expects()
    def getAngle: com.borachio.TypeSafeExpectation[Double] = mock$getAngle.expects()
    def turn(angle: com.borachio.MockParameter[Double]): com.borachio.TypeSafeExpectation[Unit] = mock$turn.expects(angle)
    def forward(distance: com.borachio.MockParameter[Double]): com.borachio.TypeSafeExpectation[Unit] = mock$forward.expects(distance)
    def penDown(): com.borachio.TypeSafeExpectation[Unit] = mock$penDown.expects()
    def penUp(): com.borachio.TypeSafeExpectation[Unit] = mock$penUp.expects()
  }
 
  private val mock$getPosition = new com.borachio.MockFunction0[(Double, Double)](factory, 'getPosition)
  private val mock$getAngle = new com.borachio.MockFunction0[Double](factory, 'getAngle)
  private val mock$turn = new com.borachio.MockFunction1[Double, Unit](factory, 'turn)
  private val mock$forward = new com.borachio.MockFunction1[Double, Unit](factory, 'forward)
  private val mock$penDown = new com.borachio.MockFunction0[Unit](factory, 'penDown)
  private val mock$penUp = new com.borachio.MockFunction0[Unit](factory, 'penUp)
}

This can then be used in tests like this:

class ControllerTest extends Suite with MockFactory {
 
  val mockTurtle = new MockTurtle(this)
  val controller = new Controller(mockTurtle)
 
  def testDrawLine() {
    inSequence {
      mockTurtle.expects.getPosition.returning((0.0, 0.0))
      mockTurtle.expects.getAngle.returning(0.0)
      mockTurtle.expects.penUp
      mockTurtle.expects.turn(~(Pi / 4))
      mockTurtle.expects.forward(~sqrt(2.0))
      mockTurtle.expects.getAngle.returning(Pi / 4)
      mockTurtle.expects.turn(~(-Pi / 4))
      mockTurtle.expects.penDown
      mockTurtle.expects.forward(1.0)
    }
 
    controller.drawLine((1.0, 1.0), (2.0, 1.0))
  }
}

There’s still a huge amount left to do:

• Support for type-parameterised methods
• Support for classes with non-trivial constructors
• Support for final classes or classes with final methods or private constructors
• Support for companion objects
• etc. etc. etc.

And hopefully the limitations on code generation in Scala compiler plugins will be lifted soon, meaning that the two-stage compilation process won’t be necessary either.

The code of the application described here is checked into GitHub.

Given that we can’t mock PowerManager directly, instead we’re going to create an interface that we can mock:

public interface PowerControl
{
    void disablePowerOff();
    void enablePowerOff();
}

Together with an implementation which will be used in production code:

public class PowerControlImpl implements PowerControl
{
    public PowerControlImpl(Context context) {
        PowerManager powerManager = (PowerManager)
            context.getSystemService(Context.POWER_SERVICE);
        wakeLock = powerManager.newWakeLock(
            PowerManager.FULL_WAKE_LOCK, "PowerControl");
    }
 
    public void disablePowerOff() {
        wakeLock.acquire();
    }
 
    public void enablePowerOff() {
        wakeLock.release();
    }
 
    private PowerManager.WakeLock wakeLock;
}

We won’t be able to test this implementation, but hopefully it’s so simple that (as Hoare puts it) it obviously contains no deficiencies (as opposed to contains no obvious deficiencies).

But we do now have something that we can mock, so we can test that the code that calls it does so correctly.

The first challenge we’re going to have to overcome is how to inject a PowerControl implementation (the real one or the mock) into the code under test. We could use a dependency injection framework like RoboGuice, but for the purposes of this article I’m going to keep things simple and use a custom Application class which implements a getPowerControl method:

public class PowerControlApplication extends Application
{
    public void onCreate() {
        powerControl = new PowerControlImpl(this);
    }
 
    public PowerControl getPowerControl() {
        return powerControl;
    }
 
    protected PowerControl powerControl;
}

Our activity calls this during onCreate:

public class PowerActivity extends Activity
{
    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
 
        PowerControlApplication app =
            (PowerControlApplication)getApplication();
        powerControl = app.getPowerControl();
    }
 
    public void startImportant(View button) {
        powerControl.disablePowerOff();
    }
 
    public void stopImportant(View button) {
        powerControl.enablePowerOff();
    }
 
    private PowerControl powerControl;
}

We can now write a test to verify that startImportant calls disablePowerOff:

class PowerActivityTest
  extends ActivityUnitTestCase[PowerActivity](classOf[PowerActivity]) 
  with MockFactory {
 
  val startIntent = new Intent(Intent.ACTION_MAIN)
 
  def testStartImportant {
    val mockPowerControl = mock[PowerControl]
    val application = new PowerControlApplication {
      powerControl = mockPowerControl
    }
    setApplication(application)
    startActivity(startIntent, null, null)
 
    withExpectations {
      mockPowerControl expects 'disablePowerOff once
 
      getActivity.startImportant(null)
    }
  }
}

Our test first creates a mock PowerControl object:

    val mockPowerControl = mock[PowerControl]

And then creates an application object that returns this mock instead of a “real” PowerControl instance:

    val application = new PowerControlApplication {
      powerControl = mockPowerControl
    }

We tell Android’s test framework to use this application object by calling setApplication:

    setApplication(application)

Finally, we set our expectation (that disablePowerOff is called once) and call startImportant:

    mockPowerControl expects 'disablePowerOff once
 
    getActivity.startImportant(null)

Updated 2011-04-15

Updated to Borachio 0.6.

But there’s a wrinkle. Android is the most test-hostile environment I’ve ever had the misfortune to find myself working in. I wonder sometimes if its designers deliberately designed it to make testing as difficult as they possibly could. It can be done, and I’ll show how in part 3, but if you’ll forgive me a digression, in this article I’m going to try the simple, “obvious” solution and demonstrate why it doesn’t work.

I’m going to try to write a simple test of an application that uses Android’s PowerManager service. PowerManager allows us to control when the device switches on or off. If we’re about to start some critical operation that must complete without the device switching off, we can obtain a WakeLock, which is what this sample app does.

The code is checked into GitHub. Here’s the code that we want to test:

package com.paulbutcher.powercontrol;
 
import android.app.Activity;
import android.os.Bundle;
import android.os.PowerManager;
import android.view.View;
 
public class PowerControl extends Activity
{
    @Override
    public void onCreate(Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);
    }
 
    public void startImportant(View button) {
        PowerManager powerManager =
            (PowerManager)getSystemService(POWER_SERVICE);
        wakeLock = powerManager.newWakeLock(
            PowerManager.FULL_WAKE_LOCK, "PowerControl");
        wakeLock.acquire();
    }
 
    public void stopImportant(View button) {
        wakeLock.release();
    }
 
    private PowerManager.WakeLock wakeLock;
}

Let’s try to write a test that verifies that startImportant calls PowerManager.newWakeLock. Our first task is going to be working out how to inject a mock PowerManager into the code under test.

That code obtains its PowerManager instance by calling Context.getSystemService. Happily, Android provides MockContext and ActivityUnitTestCase.setActivityContext, so we should be all set.

Before we get carried away, let’s just verify that we can get a test using a MockContext to run at all:

  def testAttempt1 {
    val mockContext = new MockContext;
    setActivityContext(mockContext)
    startActivity(startIntent, null, null)
  }

Let’s see what happens when we run that:

Failure in testAttempt1:
junit.framework.AssertionFailedError
  at android.test.ActivityUnitTestCase.startActivity(ActivityUnitTestCase.java:148)

Hmm—apparently this isn’t going to be as easy as we hoped.

The problem is that startActivity calls our MockContext. Specifically it calls getSystemService("layout_inflater") which fails because MockContext‘s methods are non-functional and throw UnsupportedOperationException.

It turns out that what Android means by “mock” isn’t what the rest of the world means. As Martin Fowler says in Mocks Aren’t Stubs, mocks are:

objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Never mind—there is another way. Android’s ContextWrapper allows us to wrap an existing context, only changing those bits of functionality we’re interested in for the purposes of our test:

  def testAttempt2 {
    val testContext = 
        new ContextWrapper(getInstrumentation.getTargetContext);
    setActivityContext(testContext)
    startActivity(startIntent, null, null)
  }

That works, so now we just need to modify it to return a mock PowerManager when getSystemService is called:

  def testAttempt3 {
    val mockPowerManager = mock[PowerManager]
    val testContext = 
      new ContextWrapper(getInstrumentation.getTargetContext) {
        override def getSystemService(name: String) = name match {
          case "power" => mockPowerManager
          case _ => super.getSystemService(name)
        }
      }
    setActivityContext(testContext)
    startActivity(startIntent, null, null)
  }

Which looks great, right up until we run it:

Error in testAttempt3:
java.lang.IllegalArgumentException: android.os.PowerManager is not an interface

Borachio, in common with most other mocking frameworks, can only mock interfaces, and PowerManager is a class, not an interface. There are mocking frameworks that can mock classes, for example PowerMock, but they rely on code generation, which Android’s Dalvik VM doesn’t (yet) support. So that’s not going to be any help

There’s one final thing we can try. As well as mocking interfaces, Borachio can also mock functions. So we can derive from PowerManager and just mock the single method we’re interested in like this:

  def testAttempt4 {
    val mockNewWakeLock = 
      mockFunction[Int, String, PowerManager#WakeLock]
    val mockPowerManager = new PowerManager {
      override def newWakeLock(flags: Int, tag: String) = 
        mockNewWakeLock(flags, tag)
    }
    val testContext = 
      new ContextWrapper(getInstrumentation.getTargetContext) {
        override def getSystemService(name: String) = name match {
          case "power" => mockPowerManager
          case _ => super.getSystemService(name)
        }
      }
    setActivityContext(testContext)
    startActivity(startIntent, null, null)
  }

But, when we compile this, we get:

PowerControlTest.scala:53: error: constructor PowerManager cannot be accessed in anonymous class $anon
    val mockPowerManager = new PowerManager {
                               ^

PowerManager‘s constructor is private

And at this point, we’re out of easy options. We can’t play the same trick with PowerManager as we played with Context, as there’s no PowerManagerWrapper or similar.

We’re not beaten yet—I’ll show how to get around this problem in part 3 of this series. Small wonder, however, that most of the Android code I’ve seen has virtually no tests!

One of my biggest frustrations with writing code for Android has been the fact that none of the current Java mocking frameworks work on Android’s Dalvik VM. I recently released Borachio a native Scala mocking framework which does work on Android.

Because Borachio is written in Scala, you’ll need to write your tests in Scala. But it can be used to test code written in Java.

This post demonstrates how to get basic mocking working. Things get more complicated when you try to mock bits of Android itself, but I’ll cover that in a subsequent article.

This is an Android version of the example in Martin Fowler’s article Mocks Aren’t Stubs. The code is checked into GitHub here. You’ll need to have the Android SDK and Scala 2.8 installed to run this code.

We’re going to build a (very) simple ordering system. Orders will succeed if there’s enough inventory in our warehouse and fail if not. Let’s start by creating a very simple little Android application for us to test:

1. Create a new project with:

   android create project -p WarehouseManager -t android-8 \
       -p warehousemanager -k com.example.warehousemanager \
       -a WarehouseManager

2. The core abstraction is a warehouse, represented by a Warehouse interface:

   package com.example.warehousemanager;
    
   public interface Warehouse {
       boolean hasInventory(String product, int quantity);
       void remove(String product, int quantity);
   }

3. And here’s a very simple concrete implementation of Warehouse:

   package com.example.warehousemanager;
    
   import java.util.HashMap;
    
   public class RealWarehouse implements Warehouse {
       public RealWarehouse() {
           products = new HashMap<String, Integer>();
           products.put("Talisker", 5);
           products.put("Lagavulin", 2);
       }
    
       public boolean hasInventory(String product, int quantity) {
           return inStock(product) >= quantity;
       }
    
       public void remove(String product, int quantity) {
           products.put(product, inStock(product) - quantity);
       }
    
       private int inStock(String product) {
           Integer quantity = products.get(product);
           return quantity == null ? 0 : quantity;
       }
    
       private HashMap<String, Integer> products;
   }

4. We remove things from the warehouse by placing an Order:

   package com.example.warehousemanager;
    
   public class Order {
    
       public Order(String product, int quantity) {
           this.product = product;
           this.quantity = quantity;
       }
    
       public void fill(Warehouse warehouse) {
           if (warehouse.hasInventory(product, quantity)) {
               warehouse.remove(product, quantity);
               filled = true;
           }
       }
    
       public boolean isFilled() {
           return filled;
       }
    
       private boolean filled = false;
       private String product;
       private int quantity;
   }

5. We’ll need a UI to allow us to make orders, so modify main.xml to look like this:

   <?xml version="1.0" encoding="utf-8"?>
   <LinearLayout
       xmlns:android="http://schemas.android.com/apk/res/android"
       android:orientation="vertical"
       android:layout_width="fill_parent"
       android:layout_height="fill_parent"
       >
     <TextView  
         android:layout_width="fill_parent" 
         android:layout_height="wrap_content" 
         android:text="Product:"
         />
     <EditText
         android:layout_width="fill_parent" 
         android:layout_height="wrap_content"
         android:id="@+id/product"
         />
     <TextView
         android:layout_width="fill_parent" 
         android:layout_height="wrap_content" 
         android:text="Quantity:"
         />
     <EditText
         android:layout_width="fill_parent" 
         android:layout_height="wrap_content"
         android:id="@+id/quantity"
         />
     <Button
         android:layout_height="wrap_content"
         android:layout_width="wrap_content"
         android:text="Place order"
         android:onClick="placeOrder" />
   </LinearLayout>

6. And finally, here’s the implementation of WarehouseManager:

   package com.example.warehousemanager;
    
   import android.app.Activity;
   import android.os.Bundle;
   import android.view.View;
   import android.widget.EditText;
   import android.widget.Toast;
    
   public class WarehouseManager extends Activity
   {
       /** Called when the activity is first created. */
       @Override
       public void onCreate(Bundle savedInstanceState)
       {
           super.onCreate(savedInstanceState);
           setContentView(R.layout.main);
    
           productEditText = (EditText)findViewById(R.id.product);
           quantityEditText = (EditText)findViewById(R.id.quantity);
       }
    
       public void placeOrder(View view) {
           String product = productEditText.getText().toString();
           int quantity = Integer.parseInt(quantityEditText.getText().toString());
           Order order = new Order(product, quantity);
           order.fill(warehouse);
    
           String message = order.isFilled() ? "Success" : "Failure";
           Toast toast = Toast.makeText(this, message, Toast.LENGTH_SHORT);
           toast.show();    
       }
    
       private Warehouse warehouse = new RealWarehouse();
    
       private EditText productEditText;
       private EditText quantityEditText;
   }

You should now have a little Android application that can be compiled and installed with ant install. Here’s what it looks like:

So, now that we’ve got something to test, let’s create a test project to test it:

1. Create a test project with:

   android create test-project -p test -m .. -n WarehouseManagerTest

   Next, we’ll convert this to a Scala project, as described here.

2. Add scala.dir and proguard.dir to local.properties. Here’s what I added to mine (you’ll need to change the paths to match your local installation):

   scala.dir=/opt/local/share/scala-2.8
   proguard.dir=/Users/paul/android-sdk-mac_86/tools/proguard/

3. Copy build-scala.xml into the root of the test project and add the following to build.xml:

   <import file="build-scala.xml" />
    
   <!-- Converts this project's .class files into .dex files -->
   <target name="-dex" depends="compile, scala-compile, scala-shrink">
       <scala-dex-helper />
   </target>

4. Delete the proguard.cfg file and copy the configs directory into the test project. Add the following to the bottom of both default-debug.cfg and default-release.cfg (to ensure that ProGuard doesn’t discard our test classes:

   -keep public class * implements junit.framework.Test { public void test*(); }

5. Copy the Borachio JAR to the libs directory.
6. Finally, we can write our tests, which create mock instances of the Warehouse interface:

   package com.example.warehousemanager;
    
   import junit.framework.TestCase
   import com.borachio.junit3.MockFactory
    
   class OrderTest extends TestCase with MockFactory {
    
     def testInStock() {
       withExpectations {
         val mockWarehouse = mock[Warehouse]
         inSequence {
           mockWarehouse expects 'hasInventory withArguments ("Talisker", 50) returning true once;
           mockWarehouse expects 'remove withArguments ("Talisker", 50) once
         }
    
         val order = new Order("Talisker", 50)
         order.fill(mockWarehouse)
    
         assert(order.isFilled)
       }
     }
    
     def testOutOfStock() {
       withExpectations {
         val mockWarehouse = mock[Warehouse]
         mockWarehouse expects 'hasInventory returns false once
    
         val order = new Order("Talisker", 50)
         order.fill(mockWarehouse)
    
         assert(!order.isFilled)
       }
     }
   }

7. Run the tests with:

   ant run-tests

In part 2, we’ll look at some of the challenges of mocking Android components.

Updated 2011-04-15

Updated to Borachio 0.6.