The solution was to remove the HtmlUnit included jar, xml-apis-1.3.04.

The error looked like this:

loader constraint violation: loader (instance of <bootloader>) previously initiated loading for a different type with name "org/w3c/dom/NamedNodeMap"
java.lang.LinkageError: loader constraint violation: loader (instance of ) previously initiated loading for a different type with name "org/w3c/dom/NamedNodeMap"
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2427)
at java.lang.Class.getMethod0(Class.java:2670)
at java.lang.Class.getMethod(Class.java:1603)
at net.sourceforge.htmlunit.corejs.javascript.ContextFactory.isDom3Present(ContextFactory.java:301)
at net.sourceforge.htmlunit.corejs.javascript.ContextFactory.getE4xImplementationFactory(ContextFactory.java:328)
at net.sourceforge.htmlunit.corejs.javascript.Context.getE4xImplementationFactory(Context.java:2175)
at net.sourceforge.htmlunit.corejs.javascript.ScriptRuntime.initStandardObjects(ScriptRuntime.java:222)
at net.sourceforge.htmlunit.corejs.javascript.Context.initStandardObjects(Context.java:1069)
at net.sourceforge.htmlunit.corejs.javascript.Context.initStandardObjects(Context.java:1036)
at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.init(JavaScriptEngine.java:157)
at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.access$000(JavaScriptEngine.java:68)
at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$1.run(JavaScriptEngine.java:130)
at net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:515)
at net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:507)
at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine.initialize(JavaScriptEngine.java:141)
at com.gargoylesoftware.htmlunit.WebClient.initialize(WebClient.java:1107)
at com.gargoylesoftware.htmlunit.WebWindowImpl.setEnclosedPage(WebWindowImpl.java:99)
at com.gargoylesoftware.htmlunit.html.HTMLParser.parse(HTMLParser.java:268)
at com.gargoylesoftware.htmlunit.DefaultPageCreator.createHtmlPage(DefaultPageCreator.java:127)
at com.gargoylesoftware.htmlunit.DefaultPageCreator.createPage(DefaultPageCreator.java:101)
at com.gargoylesoftware.htmlunit.WebClient.loadWebResponseInto(WebClient.java:442)
at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:329)
at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:386)
at com.gargoylesoftware.htmlunit.WebClient.getPage(WebClient.java:371)
at UIUnitTests.setUp(UIUnitTests.groovy:12)
at _GrailsTest_groovy$_run_closure4.doCall(_GrailsTest_groovy:202)
at _GrailsTest_groovy$_run_closure2.doCall(_GrailsTest_groovy:146)
at _GrailsTest_groovy$_run_closure1_closure19.doCall(_GrailsTest_groovy:112)
at _GrailsTest_groovy$_run_closure1.doCall(_GrailsTest_groovy:95)
at TestApp$_run_closure1.doCall(TestApp:66)
at gant.Gant$_dispatch_closure4.doCall(Gant.groovy:324)
at gant.Gant$_dispatch_closure6.doCall(Gant.groovy:334)
at gant.Gant$_dispatch_closure6.doCall(Gant.groovy)
at gant.Gant.withBuildListeners(Gant.groovy:344)
at gant.Gant.this$2$withBuildListeners(Gant.groovy)
at gant.Gant$this$2$withBuildListeners.callCurrent(Unknown Source)
at gant.Gant.dispatch(Gant.groovy:334)
at gant.Gant.this$2$dispatch(Gant.groovy)
at gant.Gant.invokeMethod(Gant.groovy)
at gant.Gant.processTargets(Gant.groovy:495)
at gant.Gant.processTargets(Gant.groovy:480)

During the presentation, I used Rhino to run the examples. I have seen other projects that use Rhino for unit testing, but they seemed a little heavy weight for what I wanted to do, which was to write unit tests for the project’s JavaScript and integrate it into our continuous integration environment.

The following explains what I did instead that seems to work well. I’d be interested in hearing any alternative suggestions.

To start with, I used Rhino and env.js to create a more full featured javascript runtime environment in the jvm, as John Resig wrote about a while back. I wrote about this a while back.

Because I wanted to run Rhino and execute JavaScript inside a unit test, it was easiest for me to modify the Shell example provided by the Rhino group.

Note: WordPress was blowing up on me when I tried to show the entire class… this is the abbreviated version with most of my changes.

public class Shell extends ScriptableObject {

    private boolean quitting;
    private static final long serialVersionUID = -5638074146250193112L;
    /**
     * Logger for this class.
     */
    private static final Logger logger = Logger.getLogger(Shell.class);

    @Override
    public String getClassName() {
        return "global";
    }

    public static void print(final Context cx, final Scriptable thisObj, final Object[] args, final Function funObj) {
        for (int i = 0; i < args.length; i++) {
            if (i > 0) {
                logger.info(" ");
            }

            // Convert the arbitrary JavaScript value into a string form.
            String s = Context.toString(args[i]);

            logger.info(s);
        }
    }

    public void quit() {
        quitting = true;
    }

    public static double version(final Context cx, final Scriptable thisObj,
            final Object[] args, final Function funObj) {
        double result = cx.getLanguageVersion();
        if (args.length > 0) {
            double d = Context.toNumber(args[0]);
            cx.setLanguageVersion((int) d);
        }
        return result;

    }

    public static void load(final Context cx, final Scriptable thisObj,
            final Object[] args, final Function funObj) {
        Shell shell = (Shell) getTopLevelScope(thisObj);
        for (int i = 0; i < args.length; i++) {
            shell.processSource(cx, Context.toString(args[i]));
        }
    }

    public static void assertEquals(final String expected, final String actual) {
        Assert.assertEquals(expected, actual);
    }

    public static void assertNotNull(final Object object) {
        Assert.assertTrue(!(object instanceof org.mozilla.javascript.Undefined));
        Assert.assertTrue("Provided object is null", object != null);
    }

    public static void assertTrue(final boolean condition) {
        Assert.assertTrue(condition);
    }

    public static void assertFalse(final boolean condition) {
        Assert.assertFalse(condition);
    }

}

Next I created an Abstract JUnit test that loads my Javascript environment. My setUp method looks something like this:

    protected void setUp() throws Exception {
        super.setUp();
        context = Context.enter();
        try {

            context.setOptimizationLevel(-1);
            shell = new Shell();
            context.initStandardObjects(shell);

            // Define some global functions particular to the shell. Note
            // that these functions are not part of ECMA.
            String[] names = { "print", "quit", "version", "load",
                    "assertEquals", "assertNotNull",
                    "assertTrue", "assertFalse"};
            shell.defineFunctionProperties(names, Shell.class,
                                           ScriptableObject.DONTENUM);
            shell.processSource(context, "src/test/resources/scripts/startup.js");
        } catch (Exception e) {
            e.printStackTrace();
        }

    }

This initializes the JavaScript context and loads the environment-specific javascript I want to test. In my case I wanted to test code that uses ExtJS. My startup.js script looks like this:

load('src/test/resources/scripts/env.js');
window.location='src/test/resources/scripts/empty.html';
document='src/test/resources/scripts/empty.html';
load('src/main/javascript/extjs/adapter/ext/ext-base.js');
load('src/main/javascript/extjs/ext-all-debug.js');
load('src/test/resources/scripts/resource.js');
load('src/test/resources/scripts/testdata.js');
load('target/myappcode.js');

Order is important here. First, I load env.js. Next I set values for window.location and document. I don’t use either explicitly, but some of the other files look for them. Then I load extjs, and my data and app code.

The best part about this arrangement is the predefined functions provided by the shell class. I can easily reference junit assert statements from within my javascript test.

Here is an example JUnit class:

public class PhoneNumberTest extends AbstractJSTestCase {

    public PhoneNumberTest(final String name) {
        super(name);
    }

   public void testPhoneCountryCodeRender() {
       processScript("src/test/javascript/PhoneCountryCodeRenderTest.js");
   }

   public void testCreateGrid() {
       processScript("src/test/javascript/PhoneNumberCreateGridTest.js");
   }

}

and the javascript test code it calls:

var phoneNumber = new edit.form.PhoneNumber();

assertNotNull(phoneNumber);
assertNotNull(profile);

var grid = phoneNumber.createGrid(profile);

assertNotNull(grid);

var store = grid.store;

assertNotNull(store);

assertTrue(store.getCount() === 2);

var record1 = store.getAt(0);
assertNotNull(record1);
var record2 = store.getAt(1);
assertNotNull(record2);

print(record1.data.phoneNumber);
print(record2.data.phoneNumber);

print(record1.data.extension);
print(record2.data.extension);

// Now remove the access code from the phone number
record1.data.phoneNumber = PhoneUtils.removeAccessCode(record1);
print(record1.data.phoneNumber);

record2.data.phoneNumber = PhoneUtils.removeAccessCode(record2);
print(record2.data.phoneNumber);

So how do you go about disabling a plugin now? Well the good news is you no longer have to wait 5 minutes for the Manage Configuration window to load!

Ganymede Eclipse now provides a view, the Plug-In Registry, where you can disable crappy plugins like ajdt.

In my case, I was unable to run unit tests in Eclipse until I disabled org.eclipse.ajdt.ui. Why on earth I would need ajdt to run a unit test I have no idea.

FYI, there is a new AJDT update site here. Ajdt 1.6.1 fixed the problem.

What do you do then?

Welcome to Schemamule. It’s a tiny jar file and has a single ant task which copies the entire Oracle Schema and generates a Hsqldb database. YES. It replicates an entire Oracle Schema into a hsqldb in seconds! You can either use it as an in memory database for your automated unit testing or as dev only local database for unit testing. For more details, read the original blog here.

Let me iterate the advantages:-

– Can write database dependent test cases
– Need not connect to a network for running tests
– Database tests run at blazing speed, as now they’re on hsqldb

I worked with one of the developers — Rhett Sutphin, in my earlier project. He’s a brilliant programmer. I’ve also reused it in one of my projects at a financial firm, it works great and is amazingly productive once you have setup a framework based on dbunit. Wait, what is dbunit? I’m not going into the details but it’s a no-brainer that if you use hibernate and junit, you better get started on using dbunit for unit testing backed by xml datasets instead of the cumbersome setup/teardown methods to populate data for each junit test case

We have a sample project checked into RTC’s sourceforge (We call it helloworld2), with custom classes on top of DBUnit (most of it has been written by the author of Schemamule).

My example considers of an entity, Foo with FooDao, mapped to a table Foo. For simplicity, I assume one field called name. As a step by step tutorial on extending DBUnit Unit Testing , I’ll show how simple it is to write a Dao based unit test case using Dbunit, Spring and Hibernate (of course on our generated hsqldb)

Step 1:Create an Hsqldb database from Oracle

Download Schemamule and run the following ant task

<schemacopy xmlns="http://bioinformatics.northwestern.edu/schemamule">
    <to uri="jdbc:hsqldb:file:${basedir}/hsqldb/mydb" username="sa">
    <from uri="jdbc:oracle:thin:mydb" username="scott" password="tiger">
</from>
</to></schemacopy>

Step 2: Setup DBUnit
Download the latest version of dbunit (jdk1.4 or jdk5)

Step 3: Download the svn repository (0r copy by browsing svn) Revert To Console’s sample test utility classes and example DBUnit tutorial from sourceforge here.

- Checkout under projects/unit-test.
- I’m not providing a complete working example with spring/hibernate configuration, as I presume you are running under an environment where you already have a this configured with an Oracle database.

- the utility classes include the following classes
- CoreTestCase — An extension on JUnit with much more useful assert statements
- ApplicationTestCase — All the unit tests in your Spring/Hibernate project should extend this class
- DaoTestCase — All your Dao Tests should extend this class
- ContextTools – The class which reads your applicationContext-xyz.xml file, where hibernate session is configured
- Sample Dao and entity

Configure these files in your project, which can read the applicationContext from the classpath (for the tests to work!)

Step 4:With all this configured, let’s write a simple Dao Test

public class FooDAOTest extends DaoTestCase {
    FooDao dao = (FooDao)getApplicationContext().getBean("fooDao");
         // assuming that your spring config has a bean-id 'fooDao'
	 public void testGetById() throws Exception {
            Foo foo = (Foo)dao.getById(1);
            assertEquals("revert to console", foo.getName());
	 }
}

By Default, DBUnit assumes a test data xml file in the same testdata/FooDaoTest.xml (you can override this). Now, lets see the dataset

<dataset>
<table name="FOO"><column>name</column>
        <row>
            <value>revert to console</value>
         </row></table>
</dataset>

That’s it! For all the configuration that I’ve showed you (which will take some time to setup), all you need to do to write another test is, to write another method with testdata! This setup will create,drop the testdata on the generated HsqlDb schema before/after each test. What more, because, it is in memory, you can even run, Dao Tests and complete round trip unit tests automated in your nightly builds, without coupling to an existing Oracle Schema.

There are some limitations to Schemamule though. I had to customize it for my project as we were using DB Views. I finally got it working after modifying the sourcecode. Unfortunately I could never put that back into Schemamule as a patch but I recommend downloading the source and try it for yourself. It’s a great example on understanding how Spring’s Jdbc template works and can be extended.

	private static final String PROJECTID_STR_1 = "";
	private static final String PROJECTID_STR_2 = "101/103/102/104/105/106/107";
	private static final String PROJECTID_STR_3 = "///103/104";
	private static final String PROJECTID_STR_4 = "a/b/102/104/105/106/107";

	@Test
	public void testParseProjectIds1() {
		List<integer> projectIdList1 =
			getViewBillingReportController().parseProjectIds(PROJECTID_STR_1);
		assertTrue(projectIdList1.size() == 0);
	}

	@Test
	public void testParseProjectIds2() {
		List<integer> projectIdList2 =
			getViewBillingReportController().parseProjectIds(PROJECTID_STR_2);
		assertTrue(projectIdList2.size() == 7);
	}

	@Test
	public void testParseProjectIds3() {
		List<integer> projectIdList3 =
			getViewBillingReportController().parseProjectIds(PROJECTID_STR_3);
		assertTrue(projectIdList3.size() == 2);
	}

	@Test
	public void testParseProjectIds4() {
		List<integer> projectIdList4 =
			getViewBillingReportController().parseProjectIds(PROJECTID_STR_4);
		assertTrue(projectIdList4.size() == 5);
	}

This test initially failed all but one of the assertions (it passed the happy path).

The initial method looked like this:

    public List<integer> parseProjectIds(String projectIdsStr) {
    	ArrayList<integer> result = new ArrayList<integer>();
    	int lastDelimiterLoc = -1;
    	boolean done = false;
    	while (!done) {
    		int delimiterLoc = projectIdsStr.indexOf('/', lastDelimiterLoc + 1);
    		if (delimiterLoc >= 0) {
    			String idStr = projectIdsStr.substring(lastDelimiterLoc + 1, delimiterLoc);
    			Integer id = new Integer(idStr);
   			result.add(id);
    			lastDelimiterLoc = delimiterLoc;
    		} else {
    			delimiterLoc = projectIdsStr.length();
    			String idStr = projectIdsStr.substring(lastDelimiterLoc + 1, delimiterLoc);
    			Integer id = new Integer(idStr);
    			result.add(id);
    			done = true;
    		}
        }
    	return result;
    }

I don’t know why the developer on this would have done it this way, since we already had Commons Lang available in the classpath. But after a quick refactoring I came up with this:

public List<integer> parseProjectIds(String projectIdsStr) {
    	ArrayList<integer> result = new ArrayList<integer>();
    	if(StringUtils.isNotBlank(projectIdsStr)) {
    		String[] parsedList = StringUtils.split(projectIdsStr, "/");
    		for( int i =0; i < parsedList.length; i++) {
    			if( StringUtils.isNotEmpty(parsedList[i])){
    				if( StringUtils.isNumeric(parsedList[i])) {
    					result.add(new Integer(parsedList[i]));
    				}
    			}
    		}
    	}
    	return result;
    }

This passed all my tests, and seems much more readable. This is how StringUtils rocks!

PS- StringUtils.isNotBlank also handles null values.

Your unit test extends AbstractTransactionalDataSourceSpringContextTests, and makes use of autowiring.

You write your test, run it, and receive something like this:

 Unsatisfied dependency expressed through bean property 'aController':
 No unique bean of type [org.reverttoconsole.majorapplication.controller.aController] is defined:
  expected single matching bean but found 2: [aController.htm, bController.htm]

I tried using annotations, using @Autowire and @Resource, but in the end had to refactor my code to fit the tests… by creating an Abstract class that both controllers could extend.

However, this is still limited in that it only returns the total size of the Object, not the details about the Object size in regard to its composition.

Enter monq.jar from
Whatizit.

There’s a Sizeof class in monq.jar with a static sizeof method that walks through an Object instance at runtime and counts up the bytes in use for all its elements and then returns a HashTable. The results seem to be consistent with what I’ve seen by using the java.lang.Runtime class to estimate heap size. The Sizeof class also provides a convenient printTypes method which can be used to dump the HashTable data to an OutputStream (such as System.out). This allows you to easily see which nodes of a given Object tree might be prone to causing trouble. Though it cannot be 100% accurate, it’s probably very close.

Here’s a simple usage example:

public void printObjectSizeTable(Object object) {
   Sizeof.printTypes(System.out, Sizeof.sizeof(object));
}

The above will print out a table consisting of four columns, which are:

• Count of the particular type
• Total byte size of the type
• Containing type class name
• Type class name

Example output using a populated ArrayList as the parameter to the method above:

26 1516 java.lang.Object; java.util.ArrayList
25 500 java.util.ArrayList java.util.ArrayList
1 20 java.util.ArrayList monq.stuff.Sizeof$Root
52 2036 TOTAL

I might just start integrating this into some junit tests. I certainly believe that it will be very useful in determining the cause of performance problems.

-”That’s all for now folks”

A while back I wrote about using hsqldb in unit/integration tests running in memory. The process works well because you can effectively avoid having to clean up the database before running a test, and you don’t have to worry about closing the connections in the tearDown() method either. Just kill the process and the database goes away. Provide a setup sql script and load that before running your test, and you’re golden.

But for more involved integration tests, it’s nice to be able to see the data that’s been modified. Or write a test that performs a first phase of data manipulation, followed by a second test that relies on the output of the first. This can be accomplished by an in-memory database, but it’s more satisfying for me to actually see what occurred after the test has run. I’m probably just not detail-oriented enough to set up a test thoroughly while I’m doing development, and I like being able to exam the database results visually for that added level of comfort.

Hsqldb provides some really nice configuration options for running the database as a server:

Read on to see how I set this up for my tests:

In my tests, I need to read from one db and load into another. The problem is that the database server I could use is in a remote office over a crappy network. So there’s a strong motivation for me to run my tests locally. I needed to set up two databases, and as I said earlier, I want to be able to see the results of my work. So (this is the part where the ruby on rails people laugh):

1. Configure two databases for my server
2. Configure my database explorer client
3. Configure my app to work with hsqldb

Configure two databases for my server

To configure this in Eclipse, you’ll need to create a Java App to run. Run->Run, Java Application, right-click New. Main Class will be org.hsqldb.Server. I use a separate eclipse project to store my jars, so I selected that as my project. Next add the hsqldb.jar to the classpath. You can also specify arguments, but I opted to use a server.properties file instead. You can apply or save the app now.

Since I specified my jar project for the app I created, I created a file, server.properties in the base directory of that project. The file looks like this:

#this is the default so I may not actually need this
server.port=9001

#mounts a file-based (persistent) database with alias 'clinicalconcept'
#database connection url would be 'jdbc:hsqldb:hsql://localhost/clinicalconcept'
#but '/clinicalconcept' can be omitted because database.0 is the default
server.database.0=file:C:/eceppda/work/schemadb
server.dbname.0=clinicalconcept

#mounts a file-based (persistent) database with the alias 'staged'
#datbase connection url would be 'jdbc:hsqldb:hsql://localhost/staged'
server.database.1=file:C:/eceppda/work/stagedb
server.dbname.1=staged

#Display messages in console
server.silent=false

There are of course more options you can view them here.

Configure my database explorer client

I use MyEclipse. I like it a lot. It has a database explorer plugin, among other things. So I use this database explorer. I had to specify that I was connecting to a hsqldb, and provide it with the hsqldb jar. For connection strings, I used these (one for each database):

• jdbc:hsqldb:hsql://localhost/clinicalconcept
• jdbc:hsqldb:hsql://localhost/staged

Configure my app to work with hsqldb

Lastly, in the app I’m writing I created a properties file to hold the database information:

# staging database
db.driver=org.hsqldb.jdbcDriver
db.url=jdbc:hsqldb:hsql://localhost/clinicalconcept
db.username=sa
db.password=

stage.driver=org.hsqldb.jdbcDriver
stage.url=jdbc:hsqldb:file:C:/eceppda/stagedb/stagedb
stage.username=sa
stage.password=

Then in my spring config I specify the propertyconfigurator and my datasources:

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
		<property name="locations">
			<list>
				<value>com/my/shite/resource/updater.properties</value>
			</list>
		</property>
	</bean>

	<bean id="dbSourceDS" class="org.apache.commons.dbcp.BasicDataSource">
		<property name="driverClassName">
			<value>${db.driver}</value>
		</property>
		<property name="url">
			<value>${db.url}</value>
		</property>
		<property name="username">
			<value>${db.username}</value>
		</property>
		<property name="password">
			<value>${db.password}</value>
		</property>
	</bean>

	<bean id="stageSource" class="org.apache.commons.dbcp.BasicDataSource">
		<property name="driverClassName">
			<value>${stage.driver}</value>
		</property>
		<property name="url">
			<value>${stage.url}</value>
		</property>
		<property name="username">
			<value>${stage.username}</value>
		</property>
		<property name="password">
			<value>${stage.password}</value>
		</property>
	</bean>

And that should do it. Run the app you configured in spring, you should see more verbose output that will say that it’s read the server.properties file. Refer to my previous post on loading data into the db’s for your tests…

I’m a fairly recent convert to test driven development. I’ve always thought it seemed like the right thing to do, but have only recently bought into it whole-heartedly when I took over someone else’s code base and was told the requirement’s have changed and I needed to modify it without knowing what has changed.

After writing 50+ new unit tests, I started looking for a way to streamline the process, in the form of one of the multitudes of dynamic languages now available to java. JRuby, jython, and beanshell were the favored options, as I see it (groovy looks like a promising option too, but it seems like they can’t get a 1.0 release out). It’s my understanding that beanshell has passed the latest round of jsr votes and will be a part of the jdk in the future…

Anyway I woke up in bed tonight thinking there ought to be some way to really streamline this process in Eclipse…

So imagine this:

You’re adding a new method to an existing project. Eclipse is managing the set of project dependencies, and will quickly tell you what you’ve broken after you’ve written it… and that’s great; you’ve got this wealth of information at your disposal… but doesn’t that just beg for a new plugin???

Ok, imagine, you’re writing this new method… and you can instantly move into a beanshell with an eclipse context… so you can dynamically interpret the results of your method… which is fine for simple methods with primitive signatures, but more than likely you’ll have complex objects to deal with… so add something that will generate an Easymock object for you and pass it into your beanshell and dynamically modify the context.. to help you flesh out your method with the benefit of knowing how the method will behave without the test/write/compile step. And once you’ve done that and are happy with the results, why not generate a Junit test class as a result???

So the flow would be like this; you write your method signature, create your EasyMock object(s), flesh out your method in a beanshell so you know it works correctly, and generate a Junit class with the final product.

The more I think about this, the more beneficial it seems…

MockControl myPencil = MockControl.createControl(Writer.class);

Caveat- The mocked class must implement an interface.

Next, you can get a mock implementation of the interface:

Writer mockPencil = (Writer)myPencil.getMock();

Now, with the mock and mockcontrol in hand, you can tell it how you want it to perform.

mockPencil.write("Something to write");
myPencil.setReturnType(new OutputStream());
mockPencil.erase("Something to erase");
myPencil.setVoidCallable();

And when you’re done, always call:

myPencil.replay();

Run your test, and your mock object will take the place of the real thing.

A couple other notes:

• You can specify any return type, including throwables
• You must specify the number of times you expect a method to be called, the mock will throw an exception if it receives something other than what you specify

Finally, sometimes the exceptions can be difficult to interpret. Take this recent stacktrace I received as an example:

junit.framework.AssertionFailedError:
  Unexpected method call lockHistory(Context: user=IOP-10.25.2006.05.05,workflowId=null, ( id = 00000010 (00000010) )):
    lockHistory(Context: user=IOP-10.25.2006.05.05,workflowId=null, ( id = 00000010 (00000010) )): expected: 0, actual: 1
    lockHistory(Context: user=IOP-10.25.2006.05.05,workflowId=null, ( graphUuid = 00000010 (00000010) )): expected: 1, actual: 0
at org.easymock.MockControl$4.invoke(MockControl.java:148)
at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44)
at $Proxy0.lockHistory(Unknown Source)

It’s telling me that it expected to receive a call to lockHistory with user=IOP-10.25.2006.05.05, workflowId=null, ( id = 00000010 (00000010) ). But instead it received… uh… the … same … thing?

Normally the exception provides different values and it’s not as tricky to track down the cause of the difference. I normally debug through the code as the test runs to find and fix the problem. I’ll let you know what I find in this case.