Jan 042012
 
IMG_0081 CC BY

Album

 Posted by at 13:29
Oct 302011
 
A_stack_of_newspapers (author: Daniel R. Blume, licensed under cc-by-sa-2.0) Daniel R. Blume CC BY-NC-SA

After a few hours work, my blog is now multi- (or rather bi-) lingual. Of course I didn’t go through the trouble of translating all articles and pages – I’d be busy for a week doing that. But at least the blog is now (apart from a few small remnants) – not mixed German and English, but only one of those depending on the user’s default language.

 Posted by at 18:43
May 292010
 

Finally, it’s done. I’ve released the first version of the ScalaEasyMock library (the naming is not very original, I have to admit).

ScalaEasyMock is a wrapper around the EasyMock library that focuses on mock controls and EasyMock Class Extension.

It provides a convenient, easy to use DSL for mock controls that makes heavy use of Scala manifests. Additionally, it contains helper classes that make it easy to create test objects with constructor arguments and partial mocks.

The library can be found on Google code, together with some documentation I’ve written:

Tutorial – scalaeasymock – Project Hosting on Google Code.

Happy mocking!

 Posted by at 14:48
Apr 012009
 

I finally came around to update my gallery so that it now includes all the photos I had on my original page. This led directly to a split between the wallpapers and the photos section, because it simply got a little cramped on the gallery page.

I also moved all the 4:3 sided wallpapers to ‘Older images and concept art’. While there are some among them which I do still like, that format is simply outdated. I’m thinking about re-rendering those in 16:10, even if I have to admit that this format isn’t very becoming for some of the images.

Last but not least, I have added support for Colliris PicLens. Even if the Colliris plugin is not installed (which I would advise you to change), it is a definitive improvement over the visualization modules built-in to the gallery module.

 Posted by at 22:52
Mar 172009
 
[singlepic id=542 w=240 h=180 float=left] Finally, there is something new on my page. I have to admit that I’m not 100% sure about this wallpaper… it is  a little too dark and some datails are lost in shadows. Besides, the whole setup is less then satisfying. Anyway, I guess it is as good as it will become. What I like about it is the spacescape that I did using the Astronomy plugin for Gimp… great software, and it looks somewhat like a cover from old SF stories.

 Posted by at 22:00
Aug 312008
 
The eMock quick fix

Screenshot 1: The new 'Create Mock' quick fix

This is a very simple plugin that supports unit testing with

EasyMock. It adds a new quick fix ‘Create mock’ (accessible throgh Ctrl-1) to the Java editor in Eclipse for any identifier that cannot be resolved (see Screenshot 1).

When clicked, this quick fix (which is very similiar to the ‘Add local variable’ quick fix builtin to Eclipse) adds a createMock(..) statement to the method body and a replay(..) statement directly after (see Screenshot 2).

The result of the quick fix.

Screenshot 2: Result of the applied quick fix

As I said: very simple. However, Some experience with EasyMock has shown me that exactly this is what costs the most time when writing Unit tests: 1. Create a local variable, 2. add a createMock(..) statement, 3. add a replay(..) statement… this can get *very* annoying if you have many indirections and must mock 5 or 6 items in  a row. This plugin should take away this need and thus increase productivity.

Download the eMock plugin. Simply drop the JAR file into eclipse/plugins folder. Please be aware that this is still an early version that works only with Eclipse 3.4 ‘Ganymede’ and above.

The plugin is published under EPL. I appreciate any feedback and bug reports.

May 132008
 

Are mock objects serializable? Sound’s like an idiot’s question, since no sane guy would ever consider serializing something that doesn’t really exist – that’s like trying to go to the basement of a movie mockup building.

However, as it often happens in a programmer’s life, sometimes you’re forced to behave weird. Especially with mock objects if you’re trying to feed them into a third-party library.

What I was doing is mocking parts of my application to do unit tests on a business process workflow written with Jboss’ jBPM. Specifically, I was testing a script embedded in the workflow’s XML (which prevents me from skipping the whole jBPM business and do straight tests on my Java classes).

The script calls an object that I have mocked, and I want to verify that the result gets written to the workflow’s execution context (that’s the data storage underlying it, basically a String->Object map):

There’s one big problem: jBPM is a framework with intrinsic persistence (using Hibernate) and any object written to a workflow’s execution context must be serializable (!). As I found out (the hard way, as it is often with these things): mock objects created using EasyMock (specifically, EasyMock Class Extensions) are *not* serializable, even if the class they pose as is…

When I ran straight into NotSerializableException, I tried to find ways around it. A possible tsrategy would be to add a special type converter to jBPM that allows mocks – but changing the code to be tested for testing is bad.

I thought of a lot bad solutions, I have to admit. However, the one I finally came up with is this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
public class MySerializableTest {
 
	/**
	 * The serializable class to mock.
	 */
	public static class MySerializable implements Serializable {
		private static final long serialVersionUID = -242728243854443748L;
	}
 
	/**
	 * The class that will be actually mocked. Neither the
	 * {@link MockedMySerializable#readExternal(ObjectInput)} nor
	 * {@link MockedMySerializable#writeExternal(ObjectOutput)} method will do
	 * anything - they are just there to be mocked.
	 */
	public static class MockedMySerializable extends MySerializable implements Externalizable {
 
		@Override
		public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException 
                {
			/* do nothing */
		}
 
		@Override
		public void writeExternal(ObjectOutput out) throws IOException {
			/* do nothing */
		}
	}
}

This does the trick: instead of mocking the class that implements java.io.Serializable, I create a subclass of it that implements java.io.Externalizable (for those who don’t know: that’s kind of the ‘big brother’ of Serializable which lets the user implement the actual serialization himself. Of course, I provide only a dummy implementation. Nothing will be serialized for real here, it’s just to keep the code that invokes serialization from crying.

Of course, the mock created must either be a nice mock or actually expect the writeExternal(..) method to be called. But that’s just a routine task…