A JeDi Journey (there is no certainty, only opportunity)

Ok today we gonna learn something not very new. Basically when I was working with my previous company I have’t got the chance to do mocking on my unit test or automated test ( lack of knowledge to be exact ).

To make things clear, here are the list of common words that I’ll be using in this exercise;

• unit test = automated test
• mock object = test double

This scenario will simulate on how test double will make things easier if we code to interface. Actually there are lots of benefit but I will save that part for later.

First we have the interface; 

public interface EyeTechnique
{
	String illusion();
	String readPersonality();
	String seeThrough();
}

Then here come the SUT ( system under test ) which will be using the interface. 

public class Clan
{
	private String name;
	private EyeTechnique eyeTechnique;
	private String village;

	public String getName()
	{
		return name;
	}

	public void setName(String name)
	{
		this.name = name;
	}

	public EyeTechnique getEyeTechnique()
	{
		return eyeTechnique;
	}

	public void setEyeTechnique(EyeTechnique eyeTechnique)
	{
		this.eyeTechnique = eyeTechnique;
	}

	public String getVillage()
	{
		return village;
	}

	public void setVillage(String village)
	{
		this.village = village;
	}

	public String getEnemyPersonality()
	{
		String personality = this.eyeTechnique.readPersonality();
		return personality;
	}

	public String watchEnemy()
	{
		String enemyInfo = this.eyeTechnique.seeThrough();
		return enemyInfo;
	}

	public String createIllusion()
	{
		String illusionary = this.eyeTechnique.illusion();
		return illusionary;
	}

}

And the last thing, the test class. 

import org.easymock.EasyMock;
 

import junit.framework.TestCase;

public class ClanTest extends TestCase
{
	private Clan clan;
	private EyeTechnique eyeTechnique;

	public ClanTest(String name)
	{
		super(name);
	}

	protected void setUp() throws Exception
	{
		super.setUp();
		clan = new Clan();
		eyeTechnique = EasyMock.createMock(EyeTechnique.class);
		clan.setEyeTechnique(eyeTechnique);
	}

	protected void tearDown() throws Exception
	{
		super.tearDown();
	}

	public void testGetEyeTechniqueNotNull()
	{
		//fail("Not yet implemented");
		EasyMock.replay(eyeTechnique);
		assertNotNull(clan.getEyeTechnique());

	}

	public void testCreateIllusion()
	{
		EasyMock.expect(eyeTechnique.illusion()).andReturn("mangenkyo sharingan");
		EasyMock.replay(eyeTechnique);
		assertEquals("mangenkyo sharingan", clan.createIllusion());
		EasyMock.verify(eyeTechnique);
	}
}

Ok here is the explaination especially on using test double or mocking;

eyeTechnique = EasyMock.createMock(EyeTechnique.class);

This is where easy mock will create a proxy object based on interface that we specify. In other words, a dummy/mock object. 

public void testCreateIllusion()
	{
		EasyMock.expect(eyeTechnique.illusion()).andReturn("mangenkyo sharingan");
		EasyMock.replay(eyeTechnique);
		assertEquals("mangenkyo sharingan", clan.createIllusion());
		EasyMock.verify(eyeTechnique);
	}

At line 3, this is where you expect your test class to call the test double method and return with a value ( as specify in our interface ). This part also known as recording the behaviour of test double.

Then at line 4 this is where we tell easy mock to stop recording and reply the behaviour. So when the next line exercise the SUT, this will be the test double we just recorded.

Line 6 will serve as verification stage where easymock will check whether they are missing/more behaviour than it suppose to be. It will try to match up the recorded behaviour with the one that will be call in our test method.

I think I might be missing some important things here…But not sure what.

Yes….seems I been idle since the last week, it would beneficial for me and the team if I could find something useful to do. To be more precise something that would be bring some value to the project. Hence the reason why I am and choosen to be with the team.

Frankly speaking I’m addicted to writing code especially test code. TDD bring much excitement in my career as a coder. But that only serve useful ( IMHO ) if you involve with the project from early stage. But what happen if you joining the project that already started for a few years? And to make things interesting the project doesn’t have any standard way of doing automated testing and unit testing? 

Forget about doing TDD, how about doing automated test on legacy code? Hey I’m not that great programmer/coder to begin with, but it would be great to have a safety net each to make changes to the code. Yes the one that can be run as automated test.