Our Marmites

Marmite is a spread available in the UK and a few other countries. If you’ve come across Vegemite, it’s similar. The taste is very distinctive, to the point where anyone who’s ever tried it either loves it or hates it. There is no in between. Whereas representing a persons feelings for certain types of food may require a complicated data structure, for Marmite you’d only ever need a single bit. You get the idea.

The marketing slogan in the UK is “Marmite: Love it or Hate it?”.

I often ask different people what they think about a certain product (for example, a web framework). Usually I’ll get varying feedback, but once in a while I’ll come across something that only gets two categories of answer – “Love it” or “Hate it”. It’s usually accompanied this person getting very excited or angry, going a bit red in the face and thumping the table (in a positive or negative way). There are never any inbetweeners. If people have not actually used a product, I’ll discard their opinion.

These are the Marmites of our world.

Here are some of the Marmites I’ve come across, with typical explainations I get from lovers and haters.

Maven is the Marmite of the build tool world.

  • Lovers: Consistency across projects. Common build layout and tasks. Dependency management. Does lots.
  • Haters: Poor documentation. Need the head a size of a planet to understand it.

Mac OS X is the Marmite of the desktop OS world.

  • Lovers: Beautiful. Stable. Less clutter. Less hassle. Unixy + usability. It’s not Windows.
  • Haters: Forever staring at the spinny beachball.

Ruby on Rails is the Marmite of the web application framework world.

  • Lovers: Ruby. And web sites. And ActiveRecord. And it’s oh so agile.
  • Haters: Irritating fan club. Lack of abstractions can make it hard to evolve larger systems.

Google Web Toolkit is the Marmite of the AJAX world.

  • Lovers: Allows you to use Java instead of JavaScript for building apps.
  • Haters: Allows you to use Java instead of JavaScript for building apps.

ReiserFS is the Marmite of the file system world.

  • Lovers: Excellent performance with many files and big disks. Scales well. Fast recovery through journaling. Uses space effectivley.
  • Haters: Numerous problems with fsck operations corrupting the filesystem. Future uncertain since Mr Reiser was convicted of murdering his wife.

IBM Visual Age for Java is the Marmite of the Java IDE world.

  • Lovers: A magical image of objects that can be navigating, interacted with and modified on the fly. Like Smalltalk.
  • Haters: Uhhmm. WTF is this? Where’s my source code? How do I use this thing? Isn’t this supposed to be Java?

Behaviour Driven Development is the Marmite of the development process world.

  • Lovers: It bridges the gap from requirements understanding to a live running system, with a simple metaphor.
  • Haters: It’s what now? You’ve changed the prefix from ‘test’ to ‘should’ and introduced a few words. Get away from me.

The thing to remember is to never get into a conversation with anyone about a Marmite. Either you will agree with someone and learn very little from it, or you’ll get into a fight.

So to help others avoid these awkward moments, contribute your own list of Marmites here (comments below, or trackback). Criteria: Must be something that everyone who has experience of either hates or loves – there can be no inbetween.

Qt, now a viable option for Java

Today it was announced that Qt would be made available under the LGPL license. Qt is well known in the Linux community thanks to KDE, but Qt based applications run very well on Windows and OS X, as well as many embedded platforms such as WinCE and S60.

I’m a closet Qt fan, because:

  • It has a clean OO programming model. Simple, extensible, yet not over the top.
  • It has easy to use bindings for a wide variety languages, including C++, Java, Python, Ruby, Perl, PHP, and C#.
  • It’s mature with a rich set of widgets. Including typical windowing components, a WebKit based browser, media playback, OpenGL, etc.
  • The resulting apps look good, feel fast and fit in with the native platform.
  • It’s very extensible/flexible.

Of course, on each of those points alone there are other frameworks that can beat Qt – it’s the combination of all of these that makes it so compelling.

Oh yeah, Java…

Jambi is the Qt binding layer for Java. It’s actually been very well thought out, allowing you to use pretty much any of the functionality in the C++ layer, with a simple Java API and set of conventions. It also includes bindings allowing Qt and Swing components to seamlessly co-exist in the same UI.

There are parts of the Qt Java API that make me cringe slightly (namely using reflection for event callbacks), but overall the benefits outweigh these – I’ll just have to get over the cringey bits and live with them.

I’ve used Swing and SWT extensively on some big (and small) projects. I’ve only dabbled with Qt, but from that I’ve been productive very quickly and built some solid UIs in little time. The reason why I’ve previously chosen not to use it on ‘real projects’ was due to licensing. Now that it’s LGPL, that changes everything.

If I were to start a new project tomorrow and needed a serious Java UI, Qt would be my first choice.

Ok, that wasn’t really a convincing argument. How about checking out:

Creative uses of Hamcrest matchers

The matcher API of Hamcrest is typically associated with assertThat() or mocks. I always knew other people would find good uses for it, but I never really knew what.

I particularly like these:

Collection processing

Håkan Råberg blogged about how Hamcrest can be used with iterators:

List<Integer> numbers = Arrays.asList(-1, 0, 1, 2);
List<Integer> positiveNumbers = detect(numbers, greaterThan(0)));

List<String> words = Arrays.asList("cheese", "lemon", "spoon");
List<String> wordsWithoutE = reject(words, containingString("e"));

Nothing rocket-sciencey about it. But simple and useful because it reduces boilerplate code and get to use the ever growing library of Hamcrest matchers.

On top of that, combining Hamcrest with a CGLib generated proxy, he has built a staticly typed query API:

List<Person> employees = ...;
List<Integer> allAges
= collect(from(employees).getAge());
List<Person> allBosses
= collect(from(employees).getDepartment().getBoss());
List<Person> allAccountants
= select(from(employees).getDepartment().getName(),
containingString("Accounts"));

This is nice alternative to a string based query language as you get your IDE completions, refactoring, compile time checking etc, without the noise of boilerplate code.

Web testing

Robert Chatley has taken some of the concepts of his LiFT framework and reimplemented them using Hamcrest and WebDriver for performing web testing.

public void testHasLotsOfLinks() {
goTo("http://some/url");
assertPresenceOf(greaterThan(15), links());
assertPresenceOf(atLeast(1), link().with(text(containingString("Sign in"))));

clickOn(link().with(text(containingString("Sign in"))));
assertPresenceOf(exactly(1), title().with(text(equalTo("Sign in page"))));
}

Now initially this seems a bit wordy and strange. Robert has designed this as a literate API. If you adjust the syntax highlighting of your API and make the Java keywords and syntax less visible, you get this:

goTo "http://some/url"
assertPresenceOf greaterThan 15 links
assertPresenceOf atLeast 1 link with text containingString "Sign in"

clickOn link with text containingString "Sign in"
assertPresenceOf exactly 1 title with text equalTo "Sign in page"

The motivation here is that the API usage is self documenting and could be useful to non-programmers. The flip-side to this is that it’s actually quite hard to write APIs like this and the usage can take quite a bit of getting used to.

Robert also introduced a Finder interface (the link() and title() methods return Finder implementations). This allows you to factor out your own UI specific components:

assertPresenceOf(atLeast(1), signInLink());
clickOn(signInLink());
assertPresenceOf(exactly(1),
blogLink().with(urlParameter("name", containingString("joe"))));

This is the bit I really like.

Allowing abstractions of components and matching rules to be combined in many different ways, so tests can check exactly what they need to, resulting in reduced less brittle tests that are easier to maintain.

Other uses

As I hear of other uses I’m listing them on the Hamcrest wiki.

When it goes bad

Of course, like any technology, it’s easy to get carried away.

Here’s an example of Hamcrest gone bad:

assertThat(myNumber, anyOf(equalTo(0), allOf(greaterThan(5), lessThan(10))));

I’m not a LISP programmer, so I find that really hard to understand. Just because we have an assertTHAT() method, we don’t have to use it all the time. In this case it’s much simpler to use plain old assertTRUE():

assertTrue("myNumber should be 0 or between 5 and 10",
myNumber == 0 || (myNumber > 5 && myNumber < 10));

Even though the non-Matcher version is longer (it could be shortened by leaving out the message and using a shorter variable name, but that would make it harder to understand), I find it much easier to understand.

But, what if you actually needed to use a matcher (e.g. for the web testing or collection processing examples above)?

One approach is you could use higher level matcher that are composed of other matchers:

matcher = anyOf(equalTo(0), allOf(greaterThan(5), lessThan(10)))
// simplifies to
matcher = anyOf(equalTo(0), between(5, 10))

Complete tangent: An alternative to between(5, 10) is between(5).and(10). The latter makes for more literate code, but is harder to implement – again a design tradeoff.

Another approach is to create a one-off anonymous matcher implementation:

matcher = new CustomMatcher() {
public boolean matchesSafely(Integer n) {
return n == 0 || (n > 5 && n < 10);
}
}

What are you doing with Hamcrest?

Updates:

  1. JUnit 4.4 now comes with Hamcrest and assertThat().

Hamcrest 1.1 released

http://code.google.com/p/hamcrest

Testing on the Toilet

At Google we have pretty good internal documentation, tutorials and places to find good tips. If you know you don’t know something, it won’t take long to find the answer.

However, it’s slightly tougher to place something to be read, when the target readers don’t know they don’t know it. This was a problem the testing group were finding, as they wanted to improve sharing of practical testing techniques.

So, Testing on the Toilet was started. A regular weekly(ish) tip posted in toilet cubicles and above urinals. Short enough to be read whilst doing your business.

Soon after, many visitors started noticing these postings and we got requests to make these available to put up in offices of other development teams.

So, we have.

http://googletesting.blogspot.com/

Each episode will be made available as a toilet friendly PDF.

Building testable AJAX apps (Does my button look big in this?)

Last week, Adam Connors and I presented “Does my button look big in this? Building testable AJAX applications.” at the Google London Test Automation Conference.

Unfortunately the code is unclear on the video, so you can also download the slides separately (13mb!).

QDox is back – 1.6 released

QDox history

QDox is a fast JavaDoc/Java parser built in 2002. It was originally intended as a stop gap until Java supported annotations by allowing tools to easily get access to JavaDoc attributes. Essentially it provided nothing more than a stripped down version of the JavaDoc Doclet tool, with performance suitable for using in continual build cycles (what would take JavaDoc over ten minutes to process would typically take QDox less than ten seconds). It served its purpose well.

The death of QDox

Then came along Java 5 and I stopped actively working on QDox. The first reason was that with the new annotations support, QDox wasn’t necessary. The other reason was that it would take a lot of effort to update the parser to support Java 5 syntax (not just for annotations, but generics, enums, etc).

And so QDox went quiet. The dev team lost interest and the releases stopped.

QDox is reborn

It turned out, I was wrong. Even with Java supporting annotations, QDox in a Java 5 world has some benefits:

  • Some Java 5 projects still want to use JavaDoc attributes (as well as annotations). Maybe for legacy reasons.
  • QDox acts on source code, rather than byte code. This can be useful in chicken and egg situations where you need to generate source from existing source, but you can’t compile until you’ve generated the code.
  • QDox exposes information that isn’t exposed by reflection, such as names of parameters or JavaDoc comments, which are useful for building tools to help visualize code.

So, by popular demand, I’m resurrecting the project. Yay.

1.6 released

This new release is a stop-gap release. Highlights include:

  • Switched to Apache 2.0 license.
  • Parser can now deal with Java 5 source code (annotations, generics, enums, var args, etc).
  • Numerous bugfixes.

This should be enough for existing projects to carry on using it with Java 5 code.

The next release will focus on making Java 5 specific features available in the API. Stay tuned.

Follow

Get every new post delivered to your Inbox.