This article describes Borachio, a mock object library for Scala. Unlike the popular
Java mock object libraries, Borachio does not require cglib and can therefore be used to test Android applications.
In addition, unlike its Java cousins, Borachio supports both mock objects and mock functions.

Borachio is a mock object library for Scala. Why create a new mocking library when there are already so many excellent Java mocking libraries? Because existing Java libraries:

do not handle things that Java doesn’t support, such as curried and higher-order functions.

do not support Android because the Dalvik VM doesn’t support runtime code generation. Borachio does not depend on cglib, meaning that it runs just fine on Android.

This article will show how Borachio supports both mock objects and mock functions, as well as how it can be used to test Android applications.
We'll start with mock objects.

Mock Objects

Imagine 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 at hand. The tests might run more quickly than would be the case if we ran on real hardware, and we could use mocks to simulate errors or other situations difficult to reproduce on demand.

This 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. The diagram below, for example, demonstrates the movements a turtle starting at the origin (0, 0) would need to make to draw a line from (1, 1) to (2, 1).

You can see an example of code that performs these calculations here. This isn’t trivial, so we want to test to make sure that it’s doing the right thing. Here’s a test (written with ScalaTest) that creates a mock turtle that pretends to start at the origin (0, 0) and verifies that if we ask the code we’ve just written to draw a line from (1, 1) to (2, 1) it performs the correct sequence of turns and movements:

Then, in our test, we start by setting up what we expect to happen. In this case, ordering is important, so we ensure that our functions are called in order using inSequence:

inSequence {
// expectations
}

We list which methods we expect to be called, together with their arguments. In addition, where it’s important for the functionality we’re testing, we also specify the values that our mock object should return.

There’s a wrinkle, however, because we’re dealing with floating-point numbers. If we test for simple equality, rounding errors are likely to stop our tests from passing. That’s where the ~ (tilde) operator comes in:

mockTurtle expects 'forward withArgs (~sqrt(2.0))

This says that we expect the forward method to be called with a single argument which is “close to” the square root of 2. Borachio also supports wildcard parameters (not used here) specified with an asterisk (*).

Mock Functions

Being a hybrid object/functional language, functions are first-class objects in Scala. Borachio makes mocking functions just as easy as mocking objects. Here, for example, is a test that confirms that the foldLeft function in the Scala standard library behaves as expected:

First, we create a mock function with mockFunction, which declares its argument types in a similar manner to Scala’s Function trait:

val f = mockFunction[String, Int, String]

This creates a mock function that takes two arguments, a String and an Int, and returns a String.

Then we set expectations on f in a similar manner to the mock objects we’ve already seen (the only difference being that we don’t need to specify the name of the method).

Finally, we create a sequence and call its foldLeft member:

expect("final") { Seq(0, 1, 2, 3).foldLeft("initial")(f) }

Mock Objects on Android

Because Borachio is written in pure Scala without code generation, it works just fine on Android, but you’ll need to write your tests in Scala. Borachio can, nevertheless, be used to test code written in Java.

Android’s API design can occasionally make mocking OS services challenging, but it can be done. The example below shows how we can 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.

Borachio, in common with most other mocking frameworks, can only mock interfaces. And PowerManager is a class, not an interface, so we can’t mock it directly. In addition, its constructor is private, so neither can we derive from PowerManager and just mock the methods we’re interested in. The solution, therefore, is to create an interface that we can mock:

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 Android Application class that implements a getPowerControl method:

Share your opinion

What is your opinion on Borachio's approach and syntax for mocking objects? How useful do you think it will be
to be able to mock functions? To what extent would Borachio's current inability to mock classes be a problem for you?
Discuss this article in the Articles Forum topic,
Borachio: Mock Objects for Scala and Android.