wuetender-junger-mann.de

Assuming Sun manages to get “closures” into Java7 there is still a few things that are lacking. Today I once again ran into the restrictions around annotations. The .Net solution is simply more elegant. The fact that I can’t use arbitrary classes for annotation parameters is arbitrary and promotes widespread abuse of enums. Also that these guys aren’t regular classes with methods and all is quite annoying.

Using arbitrary classes as annotations would actually make the language simpler and is therefore good…

In an earlier post I did describe a possibly better way of handling fixture tear down in JUnit.

In this post I look at the way assertions work. JUnit is actually widely used as a driver for all kinds of tests, not only unit tests. I think this is perfectly reasonable as it leverages all the support that JUnit has in IDEs and build tools.

However one problem is that a test case will be aborted on the first failed assertion. It would be nice, if you could specify, whether the failure should abort the test or just be recorded as a failure, thereby enabling better feedback on potentially longer running tests.

While this is probably generally agreed for integration/ acceptance tests I recently found that it would also be nice to have “non failing asserts” for unit tests. Let’s consider the following two unit tests for a copy constructor:

  @Test
    public void copyConstructorPopulatesCenter(){
        Circle circle = new Circle(new Point2D.Double(10,10), 2);
        Circle clone = new Circle(circle);
        assertEquals(new Point2D.Double(10,10), clone.getCenter());
    }
 
 
    @Test
    public void copyConstructorPopulatesRadius(){
        Circle circle = new Circle(new Point2D.Double(10,10), 2);
        Circle clone = new Circle(circle);
        assertEquals(2, clone.getRadius(), 0.001);
    }

While we are testing two separate things, all the setup code actually hides what the copy constructor is about, so I’d prefer to write something along these lines:

    @Test
    public void clonePopulatesFields(){
        Circle circle = new Circle(new Point2D.Double(10,10), 2);
        Circle clone = new Circle(circle);
        assertEquals(new Point2D.Double(10,10), clone.getCenter());
        assertEquals(2, clone.getRadius(), 0.001);
    }

This is much terser. The zealots will cry that there shall be only one assert per test. My thinking is, that that’s all true, but then this method contains two tests. The only (albeit not big) problem is, that when the center is not populated properly it’s preventing the second test from being executed. Another interesting observation is that having multiple “tests” in one method saves us from naming them, which in itself is a bit of an issue.

I am not sure if such a feature can be implemented by just writing a custom JUnit runner. The beautiful simplicity of the JUnit approach stems from the fact, that it uses exceptions to report failures. Thereby allowing the test code not to carry around some kind of test context. However once you have got a test context other things become possible, which I hope to elaborate on in a later post.

After all the abuse in my previous post, I feel a bit guilty. Luckily Mockito provides a way out of that problem by allowing hamcrest matchers being used to verify arguments. Here we go:

 verify(listener).propertyChange(
                (PropertyChangeEvent)argThat(
                        new HasEqualState(
                                new PropertyChangeEvent(holder, "value", "Old", "New"))));

It is not nice, but it works. Of course I also had to implement the HasEqualState matcher along these lines:

  public boolean matches(Object actual) {
            if (actual == null)
                return false;
            if (actual.getClass() != reference.getClass()) // this might be naïve
                return false;
 
            Class clazz = reference.getClass();
            for (Field field : clazz.getDeclaredFields()) {
                field.setAccessible(true);
 
                Object refValue = field.get(reference);
                Object actValue = field.get(actual);
 
                if (refValue != actValue) {
                    if (refValue == null || !refValue.equals(actValue)) {
                        return false;
                    }
                }
            }       
        return true;
    }

What troubles me with java is, that the implementors of its standard library utterly failed at setting an example. Java developers don’t know how to do proper christian oo, because every time they peek into the library sources they see C-ish hacks.

Today I realised that PropertyChangeEvent is not implementing equals based on its value.
It is almost immutable, apart from a stupid field that has been added for “future use”. And there is a lot
to be said in favour of immutable objects with value semantics.

This is, what I was trying to do:

ValueHolder holder = new ValueHolder();
holder.setValue("Old");
 
final PropertyChangeListener listener = mock(PropertyChangeListener.class);
holder.addPropertyChangeListener(listener);
 
holder.setValue("New");
 
verify(listener).propertyChange(new PropertyChangeEvent(holder, "value", "Old", "New"));

It is going to be messy…

I had a quite a few chats these days with people fro a more QAish background. Originally I intended just to look at selenium and webdriver. I showed some of the stuff, which I wrote in Java, to my QA colleagues. I used a demo webapp that implements a phonebook. My testcase just added a new contact and verified, that the user got a success message.

After they saw a bit of it, they asked me how they could separate out the testdata. I was a bit stunned, because, well it was all there – at least to me as a java developer. I had separated out everything into a method somewhat like this:

 createNewContact("Felix", "Leipold");

So I could test for other inputs as well:

 createNewContact("", "Invalid");
 createNewContact("Invalid", "");
 createNewContact("Holden", "Caulfield");

Obviously the expectation of QAs was to have an external file, e.g. a spreadsheet that feeds the data into the test code. I am very critical of this approach, but I felt like playing with junit 4 a bit. Junit 4 allows you to specify a runner four your test and indeed they have got one prepackaged that does parameterized tests. So I thought how about having a runner reads a spreadsheet and feeds the data into the test. As an example I use a very simplistic function:

    double add(double a, double b) {
        return a + b;
    }

So to test this I created this table and saved it as mathTest.xls:

Then I went on to create a test case, like this:

@RunWith(SpreadsheetDriven.class)
@Spreadsheet(name = "mathTest.xls")
public class MathTest {
    double a;
    double b;
    double expectedSum;
 
    public MathTest(Double a, Double b, Double expectedSum) {
        this.a = a;
        this.b = b;
        this.expectedSum = expectedSum;
    }
 
    @Test
    public void testAdd(){
        assertEquals(expectedSum, add(a,b));
 
    }
 
    double add(double a, double b) {
        return a + b;
 
    }
}

Essentially this thing parses the file specified in the annotation and passes it into the constructor. It’s not doing any fancy type conversions. All numerics are passed in as double, booleans as booleans, and everything else should be a string. Implementation and tests are to be found here and depend on apache poi being on the classpath for reading the excel file.

I am also quite proud of the reporting I get:

I am wondering, if all this is a good idea. But if it helps keeping people from using fit, it’s a start. What I realised by now is that actually table or data driven testing is much more appropriate for unit tests. Funnily enough that people actually do it the other way round. For unit tests I would actually recommend not to use a spreadsheet, but the original JUnit Parameterized runner, which lets you define your data like this:

    @Parameterized.Parameters
      public static List getParameters(){
        return Arrays.asList(new Object[][]
                {
                        {2,2,4},
                        {3,4,7},
                        {4,2,6},
                        {2,4,6}}
        );
    }

These days virtualisation seems to be all the rage. There are some benefits to it. It’s a way to increase the utilsation of your hardware just as pipelining increases the utilisation of the processor’s execution units. But as pipelining it comes at a price. You might increase the throughput, but the latency gets higher. Furthermore the response times become highly random, as they now depend on all the other users on the machine.

Especially in the context of development this poses a few risks. I have been working in environments with the build servers using virtual machines and shared database servers. This leads to variable build (and test) times – usually not shorter ones though!

It leads developers to ignore the time the code takes to execute, because there is no reliable feedback and all problems tends to be blamed to the environment or the database. In the worst case it leads to integration tests being ignored and abandoned, because they fail for timeouts, which result from dead slow code and unreliable system performance.

It is often said that code is to be read by humans. This is true. But it is also true and to be borne in mind, that code is run on machines. Virtualisation is clearly obscuring this fact.

Update: Dale was making the interesting point, that virtualisation is giving you a more controlled environment, because you can save your virtual machine and go back to defined points. This seems like a good thing and makes things easier in the first place. I think this is a double edged sword. In my experience you actually start incurring dependencies to that very environment. In my opinion software should be written in a way that it manages and contains it’s state. I have seen projects where you had to install database servers into the operating system (registry!). Then install stuff into the database server. Of course you also needed an application server. Everything needs to be configured. Then you run another obscure unscriptable utility to get your test data into the database. There is a huge temptation just doing these things manually and then save a snapshot of your vm. The actual problems like the use of side-effect-laden tools, resource-leakage during runtime, and poor setup-scripts remain untacled.

Writing a system that can’t work without a reboot is not a good practice. It should be a good citizen in the operating system or on the virtual machine it runs on.

I just stumbled across the concept of ZipFileSet in ant. A closer examination confirmed my suspicion. A ZipFileSet can be two pretty different things. We should stop spoiling young programmers using such outflows from a sick minds that are not capable of a single straight thought. The mainstream of java software (including the JDK) is to the software community what Hegel was to philosophy – poison that prevents all sound thinking.

Might just be the post hangover depression, but I woke up this morning with a great longing for meaning. Why do we use all kinds of tools that actually hide the meaning and intention of our programs. I’m talking about fit and fitnesse, which actually does great amount of damage to my respect for Ward Cunningham. I don’t want to hear excuses about the target audience and anything. Eventually you do want to have a full blown programming language for testing, not a macro assembler.

In the point of programming is to create and clarify meaning. Not to obscure it.

I just discovered Anna Ternheim, a nice Swedish Singersongwriter. I am listening to here Album Separation Road and try to call an external process from groovy which after all uses the Java API to perform such tasks.

Given the slightly depressing nature of the music and the slight drizzle outside, I can’t go on ranting I’m just sitting here sobbing about the sorry state of the world and the hardship of having to deal with java.lang.Runtime and java.lang.Process.

This week I started writing a few automated test cases for the jbehave eclipse plugin. I used Beck’s and Gamma’s “Contributing to Eclipse” as a starting point. They provide a simple test fixture that allows you to create java projects, packages and classes. I created a simple project with a trivial class and an even more trivial jbehave test case and launched the test case using the jbehave plugin. Then I wanted to verify the output that is been written to the console and my synchronsation problems started.

So I came up with two issues:

1. Some things like the autobuild run in background jobs, so that you have got to wait for those jobs to finish before verifying. For the autobuild there is a simple solution:

   Platform.getJobManager().join(ResourcesPlugin.FAMILY_AUTO_BUILD, null);

2. The second issue was around the update of the console, which happens in the UI thread. Unfortunatly the testcase runs in the UI thread as well, so a Thread.sleep() won’t help. The key is calling Display’s readAndDispatch() and sleep() methods to get the event queue processed while waiting. It’s still a bit awkward to work with delays, but I couldn’t come up with a better way.