Flash card Friday: 3.5 weeks late

Haven't done the flash card Friday for a while now. Been busy with stuff. But now it's finally time to get the words of wisdom rolling again. Here's a fresh batch of goodies for y'all:

• When testing a number of components in a failing setup, it is most likely that two of them are incompatible with each other
  
  Sometimes you're testing a setup with three different databases, three different app servers and three different operating systems. Testing all 27 combinations takes time. Often when something fails, it is because two components were not compatible with each other. We can therefore make sure we test all pairs of components instead. That way, we will only have 9 test cases. This reduces the time it takes for us to run the tests, while still retaining relatively good coverage. This technique is called all-pairs testing.
  
  
• Introducing tests that fail is a good thing
  
  We have been introducing more and more high-level automated tests at work lately. Some days ago I was working on a particular test that kept failing, and I was becoming aggravated. The actual feature I was testing had been in the product for quite a while. Damnit, I thought, I'm wasting a bunch of time on getting a test working for something that already works.
  
  As it turns out, the feature I was testing actually had a bug, and my failing test was simply exposing the bug. So, having tests that fail is a good thing. Aggravating none the less though.
  
  
• Balsamiq mockups are awesome
  
  Lately, at work, we've been improving our user interface a lot. This process often involves communicating ideas from/to the product owner. Roughly a month ago, a team member introduced us to Balsamiq. It's a tool for creating user interface mockups in no time. The mockups end up looking like cartoon drawings, without any flashy features such as fancy colors, fonts, and styles.
  
  A good thing about this is that users don't get hung up on the details, such as font sizes and millimeter placement of buttons, but can instead focus on the actual functionality of the GUI. The tool is also dead simple to use, and a mockup for nearly any interface can be created in five minutes. It integrates nicely with JIRA & Confluence too. Do check it out.
  
  
• Drive requirements top down
  
  When adding new features to a system, it might help to start from the user interface. This is the user's view of the system, and we should strive to root all requirements in user needs. Starting out with the UI sketches helps drive the useful requirements. It might turn out that the really cool backend feature actually wasn't needed at all, because there is no real use case for it.
  
  
• Be careful with the minimized tag form in XHTML
  
  The XHTML specification states that elements with non-empty DTD definitions should not use the minimized form (e.g. <div />). This is interesting, as it's perfectly valid XML. I have however run into problems when collapsing divs without content. Note that line breaks cannot have any content, so they may be collapsed to <br />. See the XHTML specification, section C.3, for more info.
  
  
  
• Beware of the OOM
  
  I recently learned that a Java program that runs out of memory actually can exit without an OutOfMemoryError (OOM) exception. This is due to the fact that the JVM does not have enough memory to allocate the exception. Tomcat solves this in an interesting way. At startup they allocate memory that can be freed should an OOM occur. That way, there is enough memory to shut down gracefully. Odd solution, but I guess it works.
  
  
• JSON JSP tags
  
  JSON is a wonderful thing, and sees many uses today, sometimes far away from JavaScript. If you're looking to get data from your server-side model into your client-side JavaScript data model for your dynamic interface, and are using JSP to render your view, then you should definitely check out the json-taglib project. It offers a simple set of tags to generate JSON objects and arrays from your server-side model. That's it.
  
  Now, you may be using richer frameworks for dealing with client-side JavaScript data models. If so, I'd love to hear about them.