
Nach dem Upgrade meines Webservers verfüge ich jetzt endlich wieder über genug Platz, um auch ältere Fotos zur Verfügung zu stellen. Hier ist das erste Album: “Winter in Starnberg 2006″. Weitere werden folgen…

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.
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:
Happy mocking!
Today I realized that I had never used a free domain that I have from my DSL provider. Now, I have an alternate web adress (currently redirected to www.the-anvil.net):
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.
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).
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.
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…