Symphonious

Living in a state of accord.

Abstracting Acceptance Tests

For the past three months I’ve been settling into my new role with LMAX developing a high-performance financial “exchange”1, hence the silence on the blog lately. One of the things I’ve found extremely impressive about LMAX is the impressive acceptance test coverage and the relative ease with which they are maintained. Normally as a set of acceptance tests gets to be extremely large they can become an impediment to being agile and changing the system since a small change to the UI can affect a large number of tests.

At LMAX that issue has been quite well handled by building a custom DSL for writing the acceptance tests so the acceptance tests are described at a very high level and then the details are handled in one place within the DSL – where they can be easily adjusted if the UI needs to be changed. It’s certainly not a new idea, but it’s executed better at LMAX than I’ve seen anywhere else. They regularly have not just testers but also business analysts writing acceptance tests ahead of the new functionality being developed.

One of the key reasons for the success of the DSL at LMAX is getting the level of abstraction right – much higher than most acceptance test examples use. The typical example of a login acceptance test would be something like:

  1. Open the application
  2. Enter “fred” in the field “username”
  3. Enter “mypass” in the field “password”
  4. Click the “login” button
  5. Assert that the application welcome screen is shown

However the LMAX DSL would abstract all of that away as just:

  1. Login as “fred”

The DSL knows what web page to load to login (and how to log out if it’s already logged in), what fields to fill out and has default values for the password and other fields on the login form. You can specify them directly if required, but the DSL takes care of as much as possible.

The second thing I’ve found very clever with the DSL is the way it helps to ensure tests run in an isolated environment as much as possible – even when running in parallel with other tests. There is very heavy use of aliases instead of actual values. So telling the DSL to login as “fred” will actually result in logging in as something like “fred-938797” – the real username being stored under the alias “fred” when the user was setup by the DSL. That way you have can thousands of tests all logging in as “user” and still be isolated from each other.

Interestingly, the LMAX DSL isn’t particularly English-like at all – it’s much closer to Java than English. It aims to be simple enough to understand by smart people who are working with the acceptance tests, but not necessarily the code, regularly. Sometimes developers can assume that non-developers are only capable of reading actual English text and invest too much time in making the DSL readable rather than functional, effective and efficient at expressing the requirements.

There is still a very obvious cost to building and maintaining such a large body of acceptance: some stories can require as much time writing acceptance tests as they do building the actual functionality and there is a lot of time and money invested in having enough hardware to run all those slow acceptance tests. Even so, I’ve seen a huge payoff for that effort even in the short time I’ve worked there. The acceptance tests give people the confidence to try things out and go ahead an refactor code that needs it – even it the changes also require large-scale changes to the unit tests.

1 – strictly speaking I believe it’s a multi-lateral trading facility. Don't ask me what the exact difference is.

Apple-Scented Coffee Beans are Accurate

So Apple have announced that they will be contributing large swaths of code to the OpenJDK project and that from Java 7 onwards, Java will be a separate download from Oracle, much like Flash is now a separate download from Adobe. This really shouldn’t be unexpected for anyone who was paying attention to what was going on rather than just running around thinking the sky was falling.

This is fantastic news for Java developers of all types. Mac Java developers have been asking for Java to be separated from the OS for many, many years so that multiple versions of Java are more manageable and especially to decouple Java releases from the OS release timeline.

Since the main JVM for OS X will now be open source, intrepid developers can dive in and fix issues they run into or at least dig into the code to understand it better and find work-arounds they can use. Apple has historically been quite innovative with it’s JVM port as well, bringing some great stuff to the JVM on OS X first1. It should now be easier to share those innovations across platforms which is great for all Java users.

It’s also nice to know that Java 6 will continue to be bundled with the OS in OS X 10.7 Lion. That gives a nice ramp-up for Apple and developers to transition to an optionally installed JVM and ensure things work smoothly either by applications bundling a JVM with the app or the installer or through auto-install methods for applets and webstart etc.

Finally, this should mean that JDK7 development on Mac will be done in the open, giving developers earlier and far greater access to try it out and report any issues back.

Seems like a huge win all round to me.

1 – for example the ability to share the core classes between JVM instances, but also a lot of stuff in how swing works and integrates with the OS

On the DVD vs in Software Update

James Turner gives a week in review and mentions the deprecated Java on OS X issue1. One thing to correct:

Deprecation basically means that neither package will be delivered as part of the installation DVDs, and updates will not come via the Apple update mechanisms. It doesn't mean they won't be available anymore, it just means you'll have to download them directly from Oracle and Adobe.

Firstly, there’s nothing to suggest that Java won’t come from Apple but not be part of the standard OS X package.

Secondly, just because something isn’t on the OS X install DVD doesn’t mean it’s not updated via Software Update. Aperture for example is a separately purchased product but updates come through Apple Software Update automatically. On Lion, software update is likely to open up further since it’s the obvious conduit to deliver updates for apps on the Mac App Store.

Of course, if the JVM winds up coming from Oracle, I wouldn’t hold your breath for updates via Software Update.

1 – I’m not sure how deprecated Java counts as lost in the hubbub of Back to the Mac, from where I’m sitting it looks a lot like the other way around but anyway.

Reading the Apple-Scented Coffee Beans

It’s interesting to see how many people are jumping to conclusions around the very carefully worded deprecation notice for Java in OS X. Read it carefully and pay careful attention to what it actually says:

As of the release of Java for Mac OS X 10.6 Update 3, the Java runtime ported by Apple and that ships with Mac OS X is deprecated. Developers should not rely on the Apple-supplied Java runtime being present in future versions of Mac OS X.

Most notably the note only refers to the Apple ported JVM that ships with OS X. This leaves the door open for an Apple ported JVM that ships as a separate download and for a non-Apple JVM that ships with OS X.

If you can drown out all the screaming and gnashing of teeth and pay attention to the Apple Java-Dev list you’d also notice:

  1. A huge amount of effort went into this release, especially setting things up to support multiple JVMs from multiple vendors. In the past, there was only one JVM available on an OS X install, it was upgraded with the OS and provided by Apple1.
  2. Even after this release, the Apple engineers who post to the list are still talking about their long term plans for the JVM (one example).

No one outside of Apple knows for sure what the future of Java on OS X is, and those inside who do know aren’t allowed to talk, but given the currently available evidence it seems at least as likely that Apple will continue to provide a JVM but as a separate download (or possibly just an optional install) as it is that they’ll abandon Java entirely.

Yes, there is a chance that Apple will just walk away from Java and leave a gaping void, but I don’t see indications that it’s a corporate strategy of Apple. Remember that Apple isn’t a company that sends a lot of mixed messages. They can turn a marketing message on a dime and they don’t pull punches. They’re also small enough and tightly managed enough that it’s rare for one part of the company to be off doing something that’s not inline with the company direction. If people are still building improvements to Java on OS X rather than moving to maintenance mode, that’s a strong signal that there is a future of some kind.

The real problem here is the same one that always happens with Apple – they’re not communicating their plans so developers can plan accordingly and not panic. But if you haven’t learnt to roll with the punches that approach delivers, you’re not a real Mac developer.

1 – A situation which caused most of the complaints on the java-dev list.

FireFox is Picky About Clipboard HTML, Java is Sloppy

Windows uses a particularly ugly format for putting HTML on the clipboard, called CF_HTML. Basically, it adds a header to the content with pretty useless information essentially declaring how many bytes in the header (and yes you have to pad the byte counts since they themselves are included in the count).

The problem between Java and Firefox is that Java always sets the ‘StartHTML’ and ‘EndHTML’ fields to -1 to indicate there is no context and Firefox will refuse to paste HTML from the clipboard if StartHTML or EndHTML is set to -1. As such, if you copy HTML from Java it will be impossible to paste into Firefox. It works perfectly with Word and IE.

I’m not 100% clear on whether the clipboard data Java is generating is valid but I consider it a bug in both Java and Firefox – Java for not being strict about what it outputs and Firefox for being too strict about what it accepts. Bug reports shall be made1.

On the Java side, the problem is in sun.awt.windows.WDataTrasferer.HTMLSupport.convertToHTMLFormat which sadly is Sun-specific, private and loaded from the bootclasspath so a little difficult to work around. There is however a nasty, but effective, hack from Peter Buettner which does indeed get around the problem. I’ve chosen to avoid the need to copy/paste HTML in this particular application but the approach is worth saving a reference to in case it’s needed later.

1Bug 598289 with Mozilla and there’s a simple test case available. The bug report has also been filed with Oracle and is now available in the bug parade.