public void testFindQualificationsWithEmployeeReturnsQualification()
public void testValidateQualificationsWithQualificationReturnsTrueWhereOkSkills()

For a method to be recognized by Junit to execute a test on, it must begin with the word "test". Thus, if you need helper methods in your test class, don’t start their name with "test"!

The accepted naming convention for test methods after the word test is to identify the name of the method under test, what parameters are passed in (because you may be testing other overloaded methods of the same name), what the return of the method should be (even if "void"), again due to methods of different signatures, and finally - if significant - what conditions must be met for the test to be considered a success.

Note that this naming convention works with open source frameworks you can use that will document all of the tests in your suite by parsing through the name of the test so you know exactly what the test does and which methods in the class are tested.

Be Aware of SetUp and TearDown Methods
Junit provides a great feature to make sure that each test is starting with the objects it uses in the same state.

The setUp() method, if you write it, is executed prior to Junit running each test in the class. And if you write a tearDown() method, it will be executed after each test method executes, sort of similar to a finally statement in a try/catch would.

The benefit of this is that say you need a new mock of an Employee object for each test and that this object must be in the same state for each test to make sure if there is a failure it is not because of the Employee object but because of some defect in the code operating on that Employee object. The test class itself would carry an instance property of Mock employee which is then created with its associated expectations in the setUp() method thus ensurring this continuity throughout all of the test methods in the test class.

These methods are very useful when testing calls to the database as you can run a script to drop all tables, recreate them, and then add a fresh dataset from a text or Excel file (perhaps using a tool like DbUnit).

While nothing is being done here to the Employee object, it is evident that the Accounts object will be doing something, i.e. those methods being called are going to ask questions of and perhaps even change that Employee object. But we don’t care about the Accounts object or what it does - or for that matter anything about the Employee object either. All we want to do is test the behavior of the payEmployee() method.

If we pass in a "real" Accounts object, then we can’t isolate the payEmployee() method’s activities. However, if we pass in a mock of an Accounts object, we can set expectations on the mock to do whatever we want it to do. We tell the mock what methods will be called on it, if those methods will expect certain input parameters, and what sort of return we are expecting from those method calls; all this without having the Accounts object really "do" anything.

Defining Expectations On Mocks
From the above code, we see that we are going to "expect" the Accounts object to call its employeeNotOnFile() method. Depending on what that method does, it will return a boolean result. But we don’t really care how it does what it does; all we want to know is that if we give it an Employee object it’s going to reply either true or false. Our mock would thus look like this for this one method expectation:

Mock accts = mock(IAccounts.class);
accts.
	expects(once()).
	method("employeeNotOnFile").
	with( eq((IEmployee)emp.proxy()) ).
	will( returnValue(true) );

Here, we’re telling the mock to return true because when it does, we will then test the conditional call setUpNewEmployee() method. Thus, we test both conditional branches. In this case, it’s pretty simple to do; in a more complex example you might have to write an additional expectation returning a false value.

Note the recepie for the construction of a mock object: we "expect" just "once" that the "method" employeeNotOnFile will be called and that it will be called "with" a parameter of type IEmployee, and that it "will" return a value ("returnValue") of true.

Of confusion to those new to mock objects is the ‘with( eq(xxx) )’ construct. Let’s say I have a method that takes three parameters: one of type IEmployee, one Boss, and a boolean. Our parameter definitions and the resulting statement might look like this:

Mock accts = mock(IAccounts.class);

Boss theBoss = new Boss();
theBoss.setName("Big Guy");
theBoss.setFireAuthority(true);

boolean shouldIFireSomeone = true;

accts.
- - - other expectations - - -
with(  eq((IAccounts)accts.proxy()),
		eq(theBoss),
		eq(shouldIFireSomeone)  )
- - - other expectations - - -

We use the strange looking cast (IAccounts)accts.proxy() when passing a mock as a parameter. It’s just something you have to do in comparisson to the simple concrete theBoss object we are passing in. What this signature is saying is that we expect the Accounts object will be doing some sort of work, possibly instantiating or using other objects etc so we must mock it and pass a proxy of it in the manner shown. However, all we are going to use the Boss object for is to call some accessor methods; we don’t have to mock it, we can just use it as is. It’s confusing at first, but comes intuitively later...

You test void methods and methods with no signature simply by calling them and not having an unexpected Exception or other unwanted trauma occur.

Limiting Tests To Boundary Conditions Of The Method
What this means is that we are only testing the boundary conditions of that method. Thus, a method like the following is going to be very difficult to test because we have to test the Accounts object as well as the business logic inside of the payEmployee() method:

public Money payEmployee(IEmployee emp) {
	Accounts accts = new Accounts();

	if( accts.employeeNotOnFile(emp) ) {
		accts.setUpNewEmployee(emp);
	}

	Money payment = accts.issuePay(emp);

	return payment;
}

While it might be ok to instantiate data objects inside a method, it is never appropriate to instantiate agent type objects because then you have to test them as well as the class that is supposed to be the focus of the testing! Not good... Better would be to form the method like this:

public Money payEmployee(IEmployee emp, IAccounts accts) {
	if( accts.employeeNotOnFile(emp) ) {
		accts.setUpNewEmployee(emp);
	}

	Money payment = accts.issuePay(emp);

	return payment;
}

Now, with the mock you don’t have to worry about testing the Accounts object.

Our assignment is to write a method that will pay an employee and if it is discovered that the employee is not yet on the accounting files to add him on, and then pay him.

This defination of the problem to solve is called the problem domain. We will not concern ourselves with anything outside of this small finite issue.

Create The Solution Stub
Ok, we’ll create a new service class AccountsManagerService with a method payEmployee() on it that looks like the following (skipping several of the test first steps so as not to put anyone to sleep):

class AccountsManagerService {
	public Money payEmployee(IEmployee emp, IAccounts accts) {
		return null;
	}
}

This is just a stub or place holder. It’s a starting point in creating a solution to our problem domain.

Write The Test
Now, we write our test.

public class AccountsManagerServiceTest
			extends MockObjectTestCase {
	public void
			testPayEmployeeWithEmployeeAndAccountsReturnsMoney () {
		Money payment = new Money();
		payment.setGrossPay(2000.00);
		Mock emp = mock(IEmployee.class);
		Mock accts = mock(IAccounts.class);

		AccountsManagerService svc =
				new AccountsManagerService();
		Money cash = svc.payEmployee(
				(IEmployee)emp.proxy(),
				(IAccounts)accts.proxy());

		assertNotNull(cash);
		assertEquals(
				cash.getGrossPay(),
				payment.getGrossPay(),
				0.0);
}

Notice the simplicity of the expectation of the first test, i.e. the assertNotNull test. I just stubbed in the next test because I wanted to stress how important it was not to test what you might normally think is "the" test, i.e. that the amounts match, but rather that you don’t get a null value back.

Working Through The Test

Fix And Test Again
Of course, the test will fail because the method is written to return null. So fix it:

class AccountsManagerService {
	public Money payEmployee(
			IEmployee emp,
			IAccounts accts) {
		Money payment = new Money().setValue(42.80);
		return payment;
	}
}

The Next Test Iteration
Guess what: the first test passes, but now the second one fails (because 42.80 does not equal 2000.00). So, let’s add a call to the IAccounts object to return the Money value:

class AccountsManagerService {
	public Money payEmployee(
			IEmployee emp,
			IAccounts accts) {
		Money payment = accts.issuePay(emp);
		return payment;
	}
}

The whole thing now blows up and JUnit tells us that the IAccounts object is being asked to do something and that something is not given as an expectation on the mock. So, we have to rewrite the test to account for this:

public class AccountsManagerServiceTest extends MockObjectTestCase {
	public void testPayEmployeeWithEmployee
				AndAccountsReturnsMoney () {
		Money payment = new Money();
		payment.setGrossPay(2000.00);
		Mock emp = mock(IEmployee.class);
		Mock accts = mock(IAccounts.class);
		accts.
			expects(once()).
			method("issuePay").
			with( eq((IEmployee)emp.proxy()) ).
			will( returnValue(payment) );

		AccountsManagerService svc =
				new AccountsManagerService();
		Money cash = svc.payEmployee(
				(IEmployee)emp.proxy(),
				(IAccounts)accts.proxy());

		assertNotNull(cash);
		assertEquals(
				cash.getGrossPay(),
				payment.getGrossPay(),
				0.0);
	}

Yeahhhhhhh! Both tests pass. Success.

Development Through The Remaining Problem Domain
However, we have an additional business requirement for this method. We need to make sure the employee is registered, and if not to register him. So, we add this logic into the method as follows:

class AccountsManagerService {
	public Money payEmployee(
			IEmployee emp,
			IAccounts accts) {
		if( accts.employeeNotOnFile(emp) ) {
			accts.setUpNewEmployee(emp);
		}
		Money payment = accts.issuePay(emp);
		return payment;
	}
}

And of course, when we run the test it complains that expectations need to be added to the IAccounts mock for employeeNotOnFile() and setUpNewEmployee(). So, the final form of the test would look like this:

public class AccountsManagerServiceTest extends MockObjectTestCase {
	public void testPayEmployeeWithEmployee
				AndAccountsReturnsMoney() {
		Money payment = new Money();
		payment.setGrossPay(2000.00);

		Mock emp = mock(IEmployee.class);
		Mock accts = mock(IAccounts.class);
		accts.
			expects(once()).
			method("employeeNotOnFile").
			with( eq((IEmployee)emp.proxy()) ).
			will( returnValue(true) );
		accts.
			expects(once()).
			method("setUpNewEmployee").
			with( eq((IEmployee)emp.proxy()) );
		accts.
			expects(once()).
			method("issuePay").
			with( eq((IEmployee)emp.proxy()) ).
			will( returnValue(payment) );

		AccountsManagerService svc =
				new AccountsManagerService();
		Money cash = svc.payEmployee(
				(IEmployee)emp.proxy(),
				(IAccounts)accts.proxy());

		assertNotNull(cash);
		assertEquals(
				cash.getGrossPay(),
				payment.getGrossPay(),
				0.0);
	}
}

Summing Up
And the critical thing to note from this test is that we don’t need the real Accounts object to test this method. We don’t care... We put the expectations we needed on the mock and that’s all that needed to be done.

If we would have passed the real Accounts object in, the internal workings of its employeeNotOnFile() method may have entailed, for example, a call out to the database as well as potentially instantiating other helper objects (maybe an AccountingDept object) to make its determination as to if the employee was registered or not. How do you write a simple test for that? You don’t and that’s why understanding mocks are so important.

And most important to the whole process is that the architecture of the application is designed through Interfaces that encapsulate discrete business logic and make the whole process of testing so much cleaner.

Though we can mock the IEmployee object emp, we can’t mock the Accounts object. To complicate things, let’s assume that the signature of the payEmployee() method is defined in an interface so that we can’t just turn around and pass the Accounts object in as an interface.

We find this a lot in existing code bases. The solution could be as simple as creating a new protected method payEmployeeDelegate() that does take an IAccount object and calling that from the public method (note changing the object type from Accounts to its interface type IAccounts).

public Money payEmployee(IEmployee emp) {
	IAccounts accts = new Accounts();
	return payEmployeeDelegate(emp, accts);
}


protected Money payEmployeeDelegate(IEmployee emp, IAccounts accts) {
	if( accts.employeeNotOnFile(emp) ) {
		accts.setUpNewEmployee(emp);
	}

	Money payment = accts.issuePay(emp);

	return payment;
}

Now, the full responsibility of the method can be tested through the newly refactored protected delegate method.

Even if Accounts does not have an interface that it implements, nothing adverse happens by creating one for it with any public methods it uses as part of the that interface.