Testing that an Exception is Thrown with JUnit

How do you verify your component throws an exception?

Most tests verify something works. But exceptional cases are important too, and what do many exceptional cases do? Throw exceptions of course.

So how do you verify your component throws an exception?

Real possibilities

My favourite idiom for testing exceptions is:

 
    try {
        map.locateCoordinates("Alpha Centauri");
        fail();
    } catch(OutOfBoundsException ex) {}

The code will fail() if the errant statement falls through to it; i.e. if the errant statement does not throw an exception.

Another idiom is:

 
    boolean exceptionThrown=false;
    try {
        map.locateCoordinates("Alpha Centauri");
    } catch(OutOfBoundsException ex) {
        exceptionThrown=true;
    }
    assertTrue(exceptionThrown);

I prefer the former as it’s more terse. Some may say it’s less intuitive, but that’s the whole point of idioms; they’re a good thing because they compress code, and as long as you can internalise their meaning, you can recognise what’s going on in a blink. In any event, they’re variations on a theme.

A different approach is to encapsulate the exception-throwing code in a command interface:

 
    verifyExceptionThrown(new ExceptionThrowingCommand() {
        public void exceptionThrowingBlock() {
            map.locateCoordinates("Alpha Centauri");
        }
    }
    ...
    private void verifyExceptionThrown(ExceptionThrowningCommand command) {
    try {
        command.exceptionThrowingBlock();
        fail();
    } catch(OutOfBoundsException ex) {}
    }

In this case, we’ve extracted out the idiom for verifying an exception is thrown. Unfortunately, it didn’t do much good, because calling it – due to the anonymous class declaration – is actually about as lengthy as doing the whole thing anyway! This approach does have the benefit of isolating the standard approach to exceptions, so you could for instance have a common error message. And it’s probably less error-prone; hard to err in calling the verify method. Nonetheless, it adds an extra layer of abstraction, and extra layers of abstraction should not be added lightly. So I’m still sticking with the first version.

Fantasy-land possibilities

So much for reality, how tedious. Here’s how I would like it to be done. If Java had closures – and CSharp’s anonymous method shows it’s feasible – you could call a verify method something like this:

 
    verifyExceptionThrown({map.locateCoordinates("Alpha Centauri")}); // I'm making up the syntax!

More realistically, JUnit’s reflection could quite easily be altered to let you declare a test method throws an exception:

 
    public void testGettingCoordinatesOfFarawayStarThrowsOutOfBoundsException() {
        map.locateCoordinates("Alpha Centauri")
    }

This way, by merely following the common wisdom that test methods should be self-documenting, JUnit will be able to use reflection to check that what kind of exception is thrown.

Well, maybe JBehave with its various hooks might be suited to this sort of thing.

Caveat: Sometimes You Want to Verify the Exception

Some of the above would need further modification if you are concerned about verifying details of the exception in the catch block, e.g.:

assertTrue(ex.getMessage(“Whew! That’s a bit far, what are you gonna do? Teleport yourself?!”))

In practice, there’s not too much value in doing that too often: messages are fragile, and even for other exception information, you possibly only want to check it once or twice. The rest of the time, you probably just want to know the right type of exception was thrown.

Malcolm Gladwell’s “Blink”

I just finished Malcolm Gladwell’s Blink. Here’s a few notes.

Summary

The Blink thesis can be summarised thus:

* Split-second decisions can be far more accurate than drawn-out, deliberate, “rational”, decisions. * However, split-second decisions can also be heavily flawed. * Interventions can be made to help people harness the power of split-second decisions.

Evidence of split-second decisions over deliberate decisions

  • Experiment subjects quickly started following the profitable strategy in a card game, but could not explain why until much later.
  • The running example in Blink is an art artifact which immediately made art experts suspicious, but had been deemed authentic by the deliberate legal tracking process. The Greek sculpture turned out to be a fake.
  • A singer’s talent stunned veterans of the music industry and wowed audiences, but formal audience surveys ruled him commercially inviable. Keenna turned into a big success.
  • A military simulation pitted the Blue Team, USA, against the Red Team, a rogue dictator. The Blue Team used sophisticated decision-making processes and frequent explicit communication, whereas the Red Team communicated little and relied on the intelligence of individual units. The Red Team won.

Evidence of flaws in split-second decision-making.

  • A study inferred that car salespeople judged women and blacks to be less savvy, even when all actors were attributed with the same income and professions.
  • Warren Harding ascended to American presidency on the basis of one key attribute: he looked “presidential”.
  • Doctors possessed charts of current heart activity, but their diagnoses were heavily influenced by demographic factors which were largely gratuitous in light of the charts.

Strategies to improve snap-decision making

  • Practice, practice, practice. “Expert judgment” goes hand-in-hand with “snap judgment”. Many of the benefits of quick judgments are

  • Use technology to break the instant down. Many examples involve analysing videotapes. A tennis coach works with biomechanical experts to analyse serving actions. A “mind-reader” observes muscle movements as people talk. A marriage expert dissects a conversation between couples. In some cases, this knowledge can be captured and reused in real-time. In other cases, it is simply an example of extracting big information from little moments.

  • Make first impressions count.An art director explains how he asks staff to cover items, so they can be revealed at once when his entire focus is on it. Or they will place it somewhere surprising like a wardrobe, so he’ll have the full benefit of capturing his first impressions.

  • Concentrate on the factors that matter. A care salesman does plenty of quick decision-making, judging people’s emotions and willingness to buy. But he is very conscious about judging people by their looks, because, in his opinion, appearance has nothing to do with ability to purchase. Exercises can be performed to remove biases from snap judgments.

  • Remove biasing factors. Since it may be difficult or impossible to “learn away” biases, they can be removed from consciousness so they do not factor into the decision-making process. Many musical auditions now use screens to eliminate issues such as gender and race. Likewise, a hospital has been very successful in diagnosing heart conditions by focusing doctors only on particular elements of charts and away from demographics of the patient.

  • Retain factors if they matter. As a counterpoint to the previous guideline, blind tests led Coke to introduce the “New Coke” flavour, which bombed. Part of the problem was that branding and labels do affect people’s taste judgments, and the blind tests removed those.

Quick Thoughts

This was an interesting read and it certainly makes the benefits of short-term instincts clear. In particular, the interventions were the most interesting and practical element. What I disliked was the lack of structure. The text is not especially clear about its thesis and how various points relate to it. It reads more like a collection of essays about the general topic of short-term decision-making than an entire book.

Solipsistic Relevance to Software

  • As I mentioned in Software in a Blink, software design should ideally be intuitive, so that someone can get the structure in a blink. This means eliminating extraneous code, so you can focus on the high-level details. Steve Freeman recently provided an example by way of comparing dynamic to static syntax.
  • The discussion of experts reminded me of data mining studies. For instance, stock traders can eyeball a diagram and immediately spot trends that others would be oblivious to. User interfaces for experts should be designed to exploit those abilities. For instance, I once saw a system that showed prices row-by-row, without a fixed column format. So you could have “1.234″ just above “123.4″. With no relationship between magnitude and text width, it was impossible for users to pick up patterns on the UI with which to make snap judgments.

Want Good Design Docs? Then Code Clearly!

Martin Fowler makes some good points about Code As Documentation. It fits in with Scott Ambler’s Agile Documentation text text.

In line with those, here’s my summary on documentation and agile development:

**Documents are often necessary. But for any aspect of design, prefer expressing it in code over expressing it in a document. **

Doing so obviously benefits the code base:

Self-documenting code means the code base is easier understood. This delivers value by making the code more robust and maintainable.

And – less obviously – yields great benefits for the documentation itself:

Self-documenting code means the documentation focuses on high-level matters that count. It will usually be based on industry-standard patterns that are easily conveyed in a design document, and the design document will be able to point them out and discuss how and why they have been used in the particular project context. The code will support internal reuse, so there Will be less components to document. And components will work in the same way – even when those patterns are not industry standard, they will only need to be described once.

In contrast, poor code requires detailing the minutiae of all the idiosyncratic decisions that were made. These were often made by different developers, and differ for arbitrary reasons.

When something is intrinsically clear, it requires little or no documentation. Doors don’t require instruction manuals; safety-critical chemical plants do. Where you have any choice, make your code as intuitive as the former, and this will minimise your documentation needs. The complexity of any programming problem is fixed, but it is the developer who determines how much extra complexity the code adds.

Flickr Shows Users Don’t Need Hand-Holding

The thing I like most about flickr is not its openness or RSS support or community features. They’re all great, but the thing I like most is its lack of handholding. This, to me, is the thing that differentiates it from older sites like Yahoo. It treats its users as being a bit savvy. Not complete geeks, but people who’ve used a website before.

In particular, the use of language. The Creative Commons page was down a few minutes ago, with the message “Creative Commons is having a Massage”. When you log in, it will usually say hello in a foreign language (sometimes “Aloha Mahemoff”, sometimes “Hola Mahemoff”). There’s usually some randomness going on – the front page shows different photos, the tag page highlights different tags. Even the layout seems to change if I’m not mistaken, at least on the front page.

This might all seem pretty innocuous, and the language even a bit pretentious, but I like what it all says. Many large websites have been too heavily inspired by misinterpretations of Jakob Nielsen and others. Nielsen has urged people to use simple formats, plain language, and so on. However, this was meant as a general guideline, and should be taken in the context of the time Nielsen began writing: mid-90s, when the web was new to many people, even computers were new to many people, and the pinnacle of web creativity was blinking text and mouseover surprises. The advice was never meant to cause every website to end up looking like google or yahoo.

Flickr shows how to be simple without being simplistic, straightforward without being condescending. Can that sort of design help them build a loyal fan base? Ask Apple.

Flickr Search: Breaks the Mould Too Far

Flickr’s search is flawed: it over-emphasises tags and breaks the golden rule of a search box on each page.

I like Flickr’s innovation. It’s definitely a candidate for the “2.0″ world and a big reason for the Yahoo acquisition is probably just so they can rack Flcikr brains as we enter this brave new WWW. If I was willing and able to use the verb “get it” in a sentence, I would have no problem including the Flickr team in that sentence too. Anyway, there’s plenty of valid Flickr praise around (and I’m about to post some more in the next blog entry), but it’s search just doesn’t do it for me.

Tags Ain’t Everything

Sometimes, innovation can go too far. For all the talk about tags and the folksonomy, what happened to basic search? Call me retro and all that, but I happen to like searching for an arbitrary term on a website. Instead, Flickr’s entire search revolves around tags.

To wit, look at the Flickr front page. There’s a “Find a photo of …” form, but it actually searches for matching tags. So you’ll get fairly high relevance, but you’ll miss out on many possible links. Search for “luxurious” and you’ll get just one match. Yet, have a gawk at coolme’s Ipod photo. A comment there says “How luxurious!”. Information there, but can’t be found.

I’m not trying to break into the “folksonomy” debate here. It’s an interesting conversation, but somewhat overhyped for me. What I’m saying here is, even if tags do work and you can make them more relevant with synonyms and spelling corrections and grammar adjustments, you still should allow search on other fields. I also acknowledge that comments can be irrelevant or worse, but they are nevertheless better than nothing and worthwhile using. And it’s not just comments: a flickr search could also incorporate the photo title, description, user comments, and photographer name.

These extra fields could all be made available in a complex “Advanced Search” box, but would be more popular if it was just part of the basic search. By all means, give a high relevance to tags, since they’re a specific item humans entered. But also give some respect to some of the other fields, and use them to help distinguish among photos of the same tag.

Oh-oh, We Lost the Search!

Another big usability oh-oh is the difficulty of finding the search altogether. It’s there on the front page, but not on many others – such as this help page and even the search results page. So I can’t perform two searches in a row! And you can’t search for something while you’re looking at a single photo, which I would have thought would be a fine time to search for something else. Just about every site needs a little search entry box – it’s the best value HTML can buy you per square inch. Not only is it useful, but it’s pretty-well standard web behaviour now, so you’d want a really good reason not to have it.

Searching Does What?

Finally, the search is inconsistent. Sometimes, it searches for tags as on the homepage and the tag page(http://flickr.com/photos/tags/). And sometimes it works more like what I asked for above: searching on fields such as description and title. This seems to happen when you look at all of an individuals photos. But, of course, it’s restricted to that photographer. Perhaps a tag search would give no results in many cases.

Learning by Patterns using Patterns Within Patterns

Daniel Steinberg:

There are patterns within and among patterns for many of the original GoF design patterns … A striking example is described in the latest column from Robert C. Martin’s Principles, Patterns, and Practices series: The Factory Pattern. In it he shows that “Abstract Factory is just Strategy used for creating objects.”

Yes, the original GoF patterns had many interesting relationships to each other. Many were noted in the book and many have been discussed since then. About a year ago, I created this guide to learning the GoF patterns. One “trick” is to exploit the similarities to improve the learning curve, effectively compressing the quantity of concepts that must be learned. For instance:

(6) Command (233) SIMILARITY: Command is almost identical to Strategy. That is, you call a “execute” method and the instance does it. The only difference here is Command “feels” more dynamic – it is, at some level, triggered by an external agent (e.g. an end-user). In contrast, a Strategy often represents a business rule, e.g. tax calculation. So the application may vary, but what actually happens is identical.

(10) Factory Method (107) SIMILARITY: This pattern is just a special case of Template Method. As stated in the text, it applies only to Template Methods which involve the creation of an object. Note that most people nowadays would have a different definition: a public creation method, typically of the class (or subclass) that the method belongs to.

(13) Proxy (207) Should be familiar to anyone who has used a web proxy.
(14) Decorator (175) SIMILARITY: Proxy is a special case of Decorator. It is worth learning Proxy first, because it a more familiar situation. Once understood, it is not so hard to see how a Decorator could wrap classes to perform tasks other than those performed by Proxy. Proxy is usually used with regard to security and networking, and typically a class with a proxy cannot be accessed directly. In contrast, a Decorator is usually used to enhance an existing class’s functionality. A client can freely choose whether to wrap a class with its Decorator(s). As with the Strategy-Command relationship, Decorator shares the same mechanism as Proxy, varying only in the application area and style of use.

Spam Varieties, Coping Strategies

I incur at least the following spam types:

  • Comment Spam So I disallowed comments. I’m hoping the next stable WordPress upgrade will help to fix it; otherwise, I’d be tempted to add a “I’m a human” checkbutton.
  • Trackback Spam Apparently, there is some hunger for a worthwhile online casino among readers of this blog. I need to install something like the Spam Karma plugin.
  • Referral Spam I rarely read referrer logs now. Mostly get info about incoming links via Technorati.
  • Wiki Spam Programmasaurus, the programmer’s thesaurus wiki, occasionally gets hit by a spambot, I need to set up an email or RSS notifier to watch for changes. Sadly, the robots are much more prolific than humans.
  • Mail Spam No, really. They have spam in email these days. This “mail spam” is just like wiki spam, only it gets in my inbox. Fairly minor thanks to server-side filtering and Thunderbird happily cleans up the remaining few if I’m accessing mail in from the desktop.

In addition, of course, there’s all the spam on other sites – comments on other blogs, junk sites on google. It looks like spammers will continue to find ways to innovate for a long time to come. Perhaps the only hope lies in the tiny minority of consumers who curiously make the activity profitable. If they get burned enough times, maybe they will decide to switch the internet box off. But for the next decade, it’s something to get used to.

Notepad Replacement: Vim

Coding Horror lists prices for TextPad replacements:

UltraEdit - $40

EditPlus - $30

EditPad Pro - $40

TextPad - $32

EmEditor - $40

NoteTab Pro - $20

My obligatory reaction:

  • Vim – priceless

Portable, Powerful, Programmable.

Smart IDEs are great, but there’s always a need to edit plain text files, e.g. config files on a server, and documents too. And even with IDEs, you have to use the editor to get text from your keyboard somehow. If you’re sticking with the default Eclipse/IntelliJ/JBuilder key mappings, you have to change mind-modes everytime you switch to a new IDE. And they’re pretty slow anyway. Better to use a plugin like IntelliJ-Vim to keep using the same style for adding and editing text, while retaining all the benefits of the IDE.

If you’re planning on spending several decades editing text files – writing, coding, configuring – I’d recommend taking a couple of hours to learn a decent, standard, input tool. Namely, one of vim or emacs. Here is a straightforward vim tutorial.

Music in Speech Podcasts

Lasse comments on podcast music:

The Vision Thing and Software As She’s Developed so far represent the majority of my experience with podcasts. I have to ask, what’s with the corny intros and loud music? Otherwise, I love being able to “just listen” while cooking or otherwise spacing out a bit. (emphasis mine.)

Since I’m playing a track from the Creative Commons Wired CD that I’ve heard on other podcasts, I have to concede “corny” is pretty accurate. On my TODO list is to locate a good, original, track. But priority isn’t too high.

I think a little lead-in/fade-out track is useful to establish identity. (Please excuse complete ignorance of technical terms.) Websites and blogs can have flashy logos, colour schemes, layouts to help readers distinguish them from the other 8 million offerings. Podcasts can’t do that — I can’t guarantee that anyone listening to my podcast will ever see my website (that there are any listeners at all is possibly evidence some people have not yet discovered the CSS theme in here). As the podcast space gets crowded, unique theme music or “audicons”/”earcons” will be even more important than on radio today.

As for entire songs in the middle or at the end, I’m with Lasse there. One thing I don’t much like about talkback radio is when they suddenly introduce a song. Why does that happen, and is it relevant to podcasting? I’m guessing songs occur during radio because:

  • The presenter needs a break. But radio is often live; podcasts are never live, so the presenter can just press pause instead.
  • The listener needs a break. Even in radio, this is very coarse-grained reasoning. Perhaps a few people can take a break, but most probably don’t, or in any event aren’t in a position to schedule breaks based on the presenter’s timing. In podcasting, the few who do can always press pause, or rewind a few minutes when they want to resume listening.

Now I’ve heard people say “with podcasts, you can just fast-forward the music”. But isn’t a big benefit of podcasting that you can do other things. Lasse notes that he likes listening while cooking, and others have mentioned listening to podcasts while driving, gyming, cleaning. You don’t want to interrupt all that to fast-forward. Furthermore, for those podcasts that are running advertisement slots, the music only adds to the non-core factor (although hopefully the ad slots are new and relevant).

I do like listening to music, but if I want to do that, I’ll happily switch to a music podcast. (You can play actual music on an ipod? What next?) To me, entire songs just seem out of place in the middle of a podcast on business or current affairs or whatever..

As a side note, there’s a small issue with Creative Commons licenses that doesn’t help the situation. Many, or perhaps all, of the licenses on garageband.com, and many elsewhere, require playback in their original form. I can see why artists request that, but unfortunately it rules them out of being used for title tracks, or having samples used to introduce a segment. Podcasters could mail for permission, but the objective of CC is to remove the need for explicit communication of that nature. I hope that sites like garageband will do what they can to inform artists about the implications of the CC options and make the technology easy for artists to nominate their tracks for sampling if they wish to do so.