We all know that testing objects in isolation is a good thing. (You should also test objects interacting, but that’s a different subject.)

Testing in isolation allows us to concentrate on testing a behavior without introducing additional complexity. It also allows us to strictly regulate the external state and eliminate potentially unexpected behavior. To accomplish this, we often turn to mock objects.

Mocks can do two main things:

1. Isolate the object under test from its dependencies
2. Isolate the object under test from external communication

Let’s say we want to make a self-driving car. We’ll start off with an existing vehicle.


car = new Car(make, model, year)


The first thing it needs is a robot driver.


car.driver = new RobotDriver()


Since the robot driver doesn’t need to take up a seat, we’ll throw him in the trunk so we can have another passenger. And we might as well remove the steering wheel, pedals, and shifter to make room for him. (Assume our robot driver will not malfunction so there is no need for a manual override.)


car.remove(steeringWheel)
car.remove(shifter)
car.remove(pedals)


Now we can get to our first test. We want to check how many passengers can fit into our car now.


assert.that(car.passengerCapacity()).equals(4)


For our purposes, the driver doesn’t count as a passenger.

We probably should have checked the capacity before ripping out all that stuff, and then we could write a more flexible test. We’ll also create a factory that can transform a regular car into a self-driving car.


car = new Car(make, model, year)
initialPassengerCapacity = car.passengerCapacity()
selfDrivingCar = RobotCarFactory.transform(car)
assert.that(selfDrivingCar.passengerCapacity()).is.greaterThan(initialPassengerCapacity)


All well and good, but we’ve done a lot of hand waving. Of course, there is no such robot car factory, and no robot driver (yet). That shouldn’t stop us from testing. And that’s where mocks come in.

What does a driver do?  First we need to define an interface.


interface driver {
startEngine()
stopEngine()
accelerate(speed)
decelerate(speed)
drive(duration)
turnRight(degrees)
turnLeft(degrees)
chatWithPassengers()
}


Now, as long as both a human driver and robot driver can do all of these things, they can satisfy the interface and be substituted for one another by our car.

But you might remember that we don’t actually have a robot driver. (Developers say it should be ready by next week, but they’ve been saying that for a long time.) So we create a mock:


robotDriver = mock(driver)


And now we can test it.


car.driver.startEngine()
car.driver.accelerate(milesPerHour(60))
car.driver.drive(minutes(1))
car.driver.turnRight(90)
car.driver.drive(minutes(1))
car.driver.decelerate(milePerHour(60))
car.stopEngine()


assert.that(car.distanceTraveled()).equals(miles(2))


You can see pretty explicitly here that a driver is a dependency of the car (if we want it to go anywhere.) In this case, our mock robot driver could just be a person with a remote control.

Our goal here is to show that our car works without a human driver and that there is room for an extra passenger. (So that we can obtain additional funding from our investors who want an edge in the ride-sharing marketplace.)

Stay tuned for part 2.