
Overview
This article describes difficulties waiting for us when we make
code driven by automated tests. Reader will
go through a process of implementation of a miniature system
performing some algebraic calculations with vectors.
We'll use TDD (Test Driven Development) approach to demonstrate
"test first" way of thinking. The cornerstone of our
discussion is a technique of method mocking which forces automated
test be really modular.
Good test vs Bad test
A test is robust, clear and useful when it shows how code should work
but not how it does. It is important because we have to consider tests
as business rules, active specification or up to date documentation but
not as executable appendage breaking each time when we change a code.
Thus, the main our goal is to make JUnit tests to be really modular.
If you are not familiar with JUnit or JMock, I recommend to read the
article about automated testing in Java
before. It is detailed introduction to the topic for beginners. Otherwise,
I believe that you know what we use JMock for and why developers write
automated tests at all.
OK. We've found that test should be oriented on contract rather then
implementation. It is a good point. But what the contract is and how
to make class execute its contract. Everyone knows that class' contract
is described by its interface. Concrete implementation satisfies conditions
listed in contract only on the assumption of proper work of classes it
depends on. And again, these classes should provide well defined interfaces.
That's why it is always better to supply almost each your class with interface
if you want to test a code essentially. Moreover each class already have
an interface implicitly. It is described by its public methods.
Needless to say, there are two kinds of modules in Object Oriented Programming:
classes itself and class methods. Just like as interconnection among classes
is determined by their interfaces, interconnection among methods is based on
method contracts. It includes parameters, returned value, thrown exceptions
and rules of data processing.
Summarizing it with requirement of test robustness, we come to conclusion
that the most useful and really modular tests are those tests which cover
behaviour of a single method in the assumption that all other methods work
properly. Thus, we have to mock methods of a class.
Allow me to state the last idea regarding perfect test before we start coding.
As we mentioned, automated test is a piece of documentation. Thus, it is highly
recommended to cover each special case separately to make clearer active
specification. Don't worry to create a lot of tests, there is nothing bad
excepting high time costs. I suggest to cover all edge cases as well to catch
possible bugs as early as it possible.


TDD in action
At least, we can start. Our system doesn't pretend to be the best
implementation of vector space. But it is simple enough to exercise on.
First and simplest its component is a Vector.
Remember that we are using TDD. What we have to do at first is
understand an idea of Vector and create a list of tests covering its contract.
Artefacts:
 Vector has two coordinates: X and Y
 Vector has a length
As you can see, it is simple. Only one note here. Customer asked us
to create a system in 2D. Therefore, we should not care for Z coordinate
in this step because Agile forces us to provide the most valuable
features with maximal speed. By the way, it is a very hard task
to find a balance between
flexibility/quality and speed/cost.
Tests:
 A lenght of vector (0.0, 0.0) is 0.0
 A length of vector (1.0, 1.0) is sqrt(2.0)
 A length of vector (0.0, 1.0) = length of vector (1.0, 0.0) = 1.0
 A length of vector (1.0, 1.0) = sqrt(2.0)


It is simple as well. Now we understand how vector should work
so that we can start making a test:
package com.intelrate.vector.impl;
import static org.junit.Assert.assertEquals;
import org.junit.Test;
public class VectorImplTest
{
private final double delta = 0.000001;
@Test
public void testLength1()
{
final Vector vector = new VectorImpl(0.0, 0.0);
assertEquals(0.0, vector.length(), delta);
}
}
Looks fine but doesn't work. It will not even compile bacause we haven't
yet defined neither Vector interface nor VectorImpl class. Thus, our next
step is to make this test pass. We need Vector interface.
package com.intelrate.vector;
public interface Vector
{
double length();
}
And its implementation VectorImpl:
public class VectorImpl implements Vector
{
private double x;
private double y;
public VectorImpl(final double x, final double y)
{
this.x = x;
this.y = y;
}
@Override
public double length()
{
return 0.0;
}
}
Run VectorImplTest to see green line and enjoy. But why did I write wrong implementation
of the length() method? It is not wrong because test is green. Don't be in a hurry when
you program. The most common way to make a mistake is to write wrong code before test and
then forget about test at all.
As opposed to writting all "correct" code at once we should move forward step by step.
Now we see that not all tests from our list exist. The next test is:
@Test
public void testLength2()
{
final Vector vector = new VectorImpl(1.0, 1.0);
assertEquals(Math.sqrt(2.0), vector.length(), delta);
}
Run this test to check that your implementation of class Vector fits well:
Wow! We've made a mistake. Return to code and fix it:
@Override
public double length()
{
return Math.sqrt(x * x + x * x);
}
Run tests again:
Before you hit me hard for this wrong code I want you to understand that
it is pretty cool when you see green line. Everyone likes green line.
You may think that I had grade D or C at school but there were no such grades
where I studied. The idea concludes in absence of perfect developers always
making bugfree code. If our system was complex we would make a lot of
such errors. Test driven development secures our system in case we write
rational and sufficient tests. For instance:
@Test
public void testLength3()
{
final Vector vector1 = new VectorImpl(1.0, 0.0);
final Vector vector2 = new VectorImpl(0.0, 1.0);
assertEquals(1.0, vector1.length(), delta);
assertEquals(vector1.length(), vector2.length(), delta);
}
Run it as usual too discover my fault:
As you can see, it says that code is trash. Here is the fix:
@Override
public double length()
{
return Math.sqrt(x * x + y * y);
}
Don't forget to perform two actions: 1) Run all tests 2) Enjoy green line.
At the moment you may imagine that your code is correct and perfect.
Even if it is a true, you have to follow the test plan:
@Test
public void testLength2()
{
final Vector vector = new VectorImpl(1.0, 1.0);
assertEquals(Math.sqrt(2.0), vector.length(), delta);
}
Run it:
You should be proud of your code! All tests have been implemented and line is green.
But remember that Vector should have X and Y coordinates. It is
required to supply interface with two getters. Usually getters are
too easy to broke so there is no need to cover it with JUnit. It is
a final version of Vector:
package com.intelrate.vector;
public interface Vector
{
double length();
double getX();
double getY();
}
And its implementation:
public class VectorImpl implements Vector
{
private double x;
private double y;
public VectorImpl(final double x, final double y)
{
this.x = x;
this.y = y;
}
@Override
public double length()
{
return Math.sqrt(x * x + y * y);
}
@Override
public double getX()
{
return x;
}
@Override
public double getY()
{
return y;
}
}


Vector Space
Hopefully we've just finished with baby code and now can move
toward more complex part of our system  Vector Space.
I've just shown that it is important to write a program step by step.
TDD prevents your from possible mistakes if you don't make haste and
your steps are really small. Of course, you should always think
what code you write but if tests are really good then your are done
when line is green. When developer obtains more experience in TDD their
steps are getting bigger. But one rule should be conformed: write test
first. There is a relative freedom  you can write test before code or
code after test. Both approaches are welcome so life seems to be easy.
Analysing Vector Space we've come to the next artefacts:
 Scalar product on two vectors should be determined in Vector Space
 An angle between two vectors should be determined in Vector Space
Now we should create a list of tests documenting requirements to the system.
Usually a list is being extended during implementation but I'll allow
myself to enumerate all tests we need right here:
 Scalar product of (0.0, 1.0) and (1.0, 0.0) is 0.0
 Scalar product of (2.0, 1.0) and (1.0, 2.0) is 4.0
 Scalar product of (3.0, 1.0) and (1.0, 1.0) is 2.0
 An angle between (0.0, 1.0) and (1.0, 0.0) is equal to 90°
 An angle between (√3.0, 0.0) and (√3.0, 1.0) is equal to 30°


During a work on the first test we should not care for implementation of Vector Space but
we should understand what is required to calculate scalar product. It is always better
to create mock objects because in that case we can control that Vector Space really uses
everything that it must use. Therefore, we mock two vectors and expect that getters
will be called:
package com.intelrate.vector.impl;
import static org.junit.Assert.assertEquals;
import org.jmock.Expectations;
import org.jmock.Mockery;
import org.junit.Test;
import org.jmock.integration.junit4.JMock;
import org.jmock.integration.junit4.JUnit4Mockery;
import org.junit.runner.RunWith;
@RunWith(JMock.class)
public class VectorSpaceImplTest
{
private final double delta = 0.000001;
private Mockery context = new JUnit4Mockery();
private VectorSpace vectorSpace = new VectorSpaceImpl();
private Vector vector1 = context.mock(Vector.class, "vector1");
private Vector vector2 = context.mock(Vector.class, "vector2");
@Test
public void testScalarProduct1()
{
final double x1 = 0.0, x2 = 1.0, y1 = 1.0, y2 = 0.0;
final double expectedScalarProduct = 0.0;
context.checking(new Expectations() { {
one(vector1).getX(); will(returnValue(x1));
one(vector2).getX(); will(returnValue(x2));
one(vector1).getY(); will(returnValue(y1));
one(vector2).getY(); will(returnValue(y2));
} });
assertEquals(expectedScalarProduct,
vectorSpace.scalarProduct(vector1, vector2), delta);
}
@Test
public void testScalarProduct2()
{
final double x1 = 2.0, x2 = 1.0, y1 = 1.0, y2 = 2.0;
final double expectedScalarProduct = 4.0;
context.checking(new Expectations() { {
one(vector1).getX(); will(returnValue(x1));
one(vector2).getX(); will(returnValue(x2));
one(vector1).getY(); will(returnValue(y1));
one(vector2).getY(); will(returnValue(y2));
} });
assertEquals(expectedScalarProduct,
vectorSpace.scalarProduct(vector1, vector2), delta);
}
@Test
public void testScalarProduct3()
{
final double x1 = 3.0, x2 = 1.0, y1 = 1.0, y2 = 1.0;
final double expectedScalarProduct = 2.0;
context.checking(new Expectations() { {
one(vector1).getX(); will(returnValue(x1));
one(vector2).getX(); will(returnValue(x2));
one(vector1).getY(); will(returnValue(y1));
one(vector2).getY(); will(returnValue(y2));
} });
assertEquals(expectedScalarProduct,
vectorSpace.scalarProduct(vector1, vector2), delta);
}
}
Please note that you have to give explicit names to mock vectors.
Otherwise, JMock gives it default name based on class name so
IllegalArgumentException will be thrown with message "a mock with
name vector already exists". And never forget delta when compare
values of type double. You should not check manually that all expectations
are satisfied because JMock does it for you implicitly.
To make the test above compile we must provide VectorSpace interface:
package com.intelrate.vector;
public interface VectorSpace
{
/**
* Calculates a scalar product of two given vectors.
*/
double scalarProduct(final Vector vector1, final Vector vector2);
}
And its implementation VectorSpaceImpl:
package com.intelrate.vector.impl;
import com.intelrate.vector.Vector;
import com.intelrate.vector.VectorSpace;
public class VectorSpaceImpl implements VectorSpace
{
@Override
public double scalarProduct(final Vector vector1, final Vector vector2)
{
return vector1.getX() * vector2.getX() + vector1.getY() * vector2.getY();
}
}
According to our technique, run all JUnit tests:
It is very important to have all tests successfully passing. Once some
test is broken, repairing of it should be a highest priority task.
I strongly recommend to use Continuous Integration. Automate the build,
make it selftesting and always keep it in stable state.
So far so good. Now we are smart enough to discuss the most interesting
question of our investigation. Let us implement the last two tests from the list.
It is known that scalar product of vectors A and B is equal to A * B * cos(A^B).
Thus, getters and length methods will be called for each vector:
@Test
public void testAngle1()
{
final double x1 = 0.0, x2 = 1.0, y1 = 1.0, y2 = 0.0;
final double expectedAngle = 90.0;
context.checking(new Expectations() { {
one(vector1).getX(); will(returnValue(x1));
one(vector2).getX(); will(returnValue(x2));
one(vector1).getY(); will(returnValue(y1));
one(vector2).getY(); will(returnValue(y2));
one(vector1).length(); will(returnValue(1.0));
one(vector2).length(); will(returnValue(1.0));
} });
assertEquals(expectedAngle,
vectorSpace.angle(vector1, vector2), delta);
}
@Test
public void testAngle2()
{
final double x1 = Math.sqrt(3.0), x2 = Math.sqrt(3.0), y1 = 0.0, y2 = 1.0;
final double expectedAngle = 30.0;
context.checking(new Expectations() { {
one(vector1).getX(); will(returnValue(x1));
one(vector2).getX(); will(returnValue(x2));
one(vector1).getY(); will(returnValue(y1));
one(vector2).getY(); will(returnValue(y2));
one(vector1).length(); will(returnValue(Math.sqrt(3.0)));
one(vector2).length(); will(returnValue(2.0));
} });
assertEquals(expectedAngle,
vectorSpace.angle(vector1, vector2), delta);
}
Add method angle to the VectorSpace Interface:
package com.intelrate.vector;
public interface VectorSpace
{
/**
* Calculates a scalar product of two given vectors.
*/
double scalarProduct(final Vector vector1, final Vector vector2);
/**
* Calculates an angle between vectors.
*
* @return angle in degrees
*/
double angle(final Vector vector1, final Vector vector2);
}
And implement it:
@Override
public double angle(final Vector vector1, final Vector vector2)
{
final double scalar = scalarProduct(vector1, vector2);
final double square = Math.abs(vector1.length() * vector2.length());
final double piDegree = 180.0;
return Math.acos(scalar / square) * piDegree / Math.PI;
}
As you may consider, we'll get green line as a result of tests execution:
That's great! Actually, we'll not change VectorSpaceImpl class any more.
Nevertheless, if you work on real system using TDD, refactoring of code is the must.
I've encountered that TDD forces us to put all the code in one class and,
what is more, in one method. Neddless to explain why it is bad.
Our system is small so I managed to implement VectorSpaceImpl well at once.
Further coding concerns to improvement of VectorSpaceImplTest.
Look at this:
@RunWith(JMock.class)
public class VectorSpaceImplTest
{
private final double delta = 0.000001;
private Mockery context = new JUnit4Mockery();
private VectorSpace vectorSpace = new VectorSpaceImpl();
private Vector vector1 = context.mock(Vector.class, "vector1");
private Vector vector2 = context.mock(Vector.class, "vector2");
@Test
public void testAngle2()
{
final double x1 = Math.sqrt(3.0), x2 = Math.sqrt(3.0), y1 = 0.0, y2 = 1.0;
final double expectedAngle = 30.0;
context.checking(new Expectations() { {
one(vector1).getX(); will(returnValue(x1));
one(vector2).getX(); will(returnValue(x2));
one(vector1).getY(); will(returnValue(y1));
one(vector2).getY(); will(returnValue(y2));
one(vector1).length(); will(returnValue(Math.sqrt(3.0)));
one(vector2).length(); will(returnValue(2.0));
} });
assertEquals(expectedAngle,
vectorSpace.angle(vector1, vector2), delta);
}
}
The test is brittle and it is too hard to prepare test data.
Test testAngle2() will fail not only if the method calculating
angle is broken. If we make a mistake in calculation of
scalar product, it will affect testAngle2() as well.
Fortunately, it doesn't depend on vector.length() implementation
because we use mock vectors.
As a result of dependency on scalarProduct method, we
have to mock too many calls required for its proper work.
Imagine that you have a method invoking 5 or 7 other
methods of a class containing it. It means that you will
copy and paste expectations for all these methods as we've
done it for scalar product calculation.
At the beginning of this article we've figured out that test should be modular.
Don't afraid to refactor your tests because it is a part of your system and
evolves with it. But what can we do? The simplest solution consists in
introduction of inner class extending a class under the test:
@RunWith(JMock.class)
public class VectorSpaceImplTest
{
private final double delta = 0.000001;
private Mockery context = new JUnit4Mockery();
private Vector vector1 = context.mock(Vector.class, "vector1");
private Vector vector2 = context.mock(Vector.class, "vector2");
private boolean scalarIsInvoked;
@Test
public void testAngle2()
{
final VectorSpace vectorSpace = new VectorSpaceImpl() {
public double scalarProduct(final Vector vector1, final Vector vector2) {
scalarIsInvoked = true;
return 3.0;
}
};
final double expectedAngle = 30.0;
context.checking(new Expectations() { {
one(vector1).length(); will(returnValue(Math.sqrt(3.0)));
one(vector2).length(); will(returnValue(2.0));
} });
scalarIsInvoked = false;
assertEquals(expectedAngle,
vectorSpace.angle(vector1, vector2), delta);
assertTrue(scalarIsInvoked);
}
}
Run the test to ensure that everything is fine. This version
is robust because it doesn't depend on implementation of
scalarProduct() method. At the same time it strictly verifies
a contract of angle() excluding possibility of overlapped
mistakes producing correct result. And, in my opinion,
it is much more easier to understand by this test
how an angle() method should work.
But scalarIsInvoked variable doesn't look like a cool thing at all.
It is also better to see human readable expectations rather then
operate with private fields. The next piece of code resolves these issues:
@RunWith(JMock.class)
public class VectorSpaceImplTest
{
private final double delta = 0.000001;
private Mockery context = new JUnit4Mockery();
private Vector vector1 = context.mock(Vector.class, "vector1");
private Vector vector2 = context.mock(Vector.class, "vector2");
private VectorSpace mockVectorSpace = context.mock(VectorSpace.class);
@Test
public void testAngle2()
{
final VectorSpace vectorSpace = new VectorSpaceImpl() {
public double scalarProduct(final Vector vector1, final Vector vector2) {
return mockVectorSpace.scalarProduct(vector1, vector2);
}
};
final double expectedAngle = 30.0;
context.checking(new Expectations() { {
one(vector1).length(); will(returnValue(Math.sqrt(3.0)));
one(vector2).length(); will(returnValue(2.0));
one(mockVectorSpace).scalarProduct(vector1, vector2); will(returnValue(3.0));
} });
assertEquals(expectedAngle,
vectorSpace.angle(vector1, vector2), delta);
}
}
This code is clearer and looks more proficient. At the same time it
provides full access to all abilities of JMock including parameter
verification which was hard to implement using previous approach.
Don't forget to run all tests before you go home!
It was the last idea I wanted to talk about today. Big thanks to
Dmitry Kalashnikov who suggested how to mock class method in
the best way. Special thanks to Dmitry Lobasev for very productive
seminar about test driven development.
And thank you, my dear reader, for your attention and tolerance to
my English :)
