Jan 042012
 
IMG_0081 CC BY

Zum Album

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

So, nach ein paar Stunden Arbeit ist mein Blog jetzt mehr-, oder besser gesagt zweisprachig. Natürlich habe ich mir nicht die Mühe gemacht, sämtliche Beiträge und Seiten zu übersetzen. Da wäre ich wohl eine Woche beschäftigt. Aber immerhin ist das Blog jetzt – von ein paar Ausreißern abgesehen – nicht mehr gemischt Deutsch und Englisch, sondern je nach Auswahl nur noch eines von beiden.

 Posted by at 18:43
Mai 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
 

Ich bin schließlich mal dazu gekommen, meine Galerie zu aktualisieren, so daß nun auch alle Fotos zu sehen sind, die ich auf meiner ursprünglichen Seite hatte. Da dies dazu führte, daß es auf der ursprünglichen Galerie etwas zu eng wurde, habe ich Wallpaper und Fotos jetzt auf zwei unterschiedlichen Seiten untergebracht.

Alle Wallpaper im Format 4:3 finden sich jetzt im Archiv – es gibt zwar einige unter ihnen, die ich noch ganz schön finde, aber dieses Format ist einfach veraltet. Ich denke darüber nach, einige der Bilder neu in 16:10 oder 16:9 zu rendern, aber für manche ist das neue Format einfach schlecht geeignet.

Zu guter Letzt unterstützt meine Seite jetzt Colliris PicLens. Auch wenn das Colliris Plugin nicht installiert ist, ist es eine definitive Verbesserung gegenüber den eingebauten Visualisierungs-Plugins.

 Posted by at 22:52
Mär 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.

Mai 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…