behaviour driven unit test design in Java

Writing unit tests is not that hard but writing good unit tests which, when they fail, tell you exactly and verbosely why and where it did not go right is not as trivial as it seems.

Let’s say we have a class that represents a square. The only operations we can perform on a square are: getting its surface and doubling the side length.

public class Square {

  private int sideLength;

  public Square(int sideLength) {
    this.sideLength = sideLength;
  }

  public int getSurface() {

    return this.sideLength * this.sideLength;

  }

  public void doubleSideLength() {

    this.sideLength = this.sideLength * 2;

  }

}

To test that piece of code, we could probably write a unit test that will look like:

public class SquareTest {

  public void testSurfaceWhenSideLengthIsDoubled() {

    Square a = new Square(5);
    Square b = a; b.doubleSideLength();

    assertEquals(a.getSurface(), b.getSurface() / 4);

  }

}

From a programmer’s point of view the code above perfectly makes sense but – even if the example is rather simple – it does not really tells us what scenario we want to test here. If this piece code would be read by a product manager, she would probably not understand it (oh well, in that case she probably will but unit tests can be a lot more complex than that).

What about making the code a little bit clearer and telling us a story? There are frameworks for that you could argue (like JBehave) but do we need a framework – and all the configuration, XML files that come with – for everything really? What if we just rewrite the test class so it is more narrative?

public class SquareTestEnhanced {

  private Square square;

  public void test_side_length_x_2_gives_surface_x_4() {

    when_doubling_is_done_on(new Square(5));
    then_surface_must_be_multiplied_by_4();

  }

  private void when_doubling_is_done_on(Square s) {

    this.square = s;

  }

  private void then_surface_must_be_multiplied_by_4() {

    Square s = this.square; s.doubleSideLength();
    assertEquals(this.square.getSurface() * 4, s.getSurface());

  }

}

Isn’t it enough? Can my product manager understand what we are testing between lines 5 and 10?

an overview of the NoSQL world

A few sessions at the Disruptive Code conference were dedicated to the “NoSQL solutions” trendy topic and I was really looking forward – I have to admit – to what Adam Skogman (from SpringSource) and Eric Evans (from Rackspace) had to say on the subject.

In the last 5 years the amount of data produced worldwide (texts, images, audio, …) has drastically increased from 161 exabytes to 988 exabytes (one EB being one million TB or one billion GB) and with that come some new challenges (storage capacity, availability, …) that cannot be entirely solved by SQL solutions and relational databases.

Not entirely because “NoSQL” does not mean no SQL at all but not only SQL really and a mixed architecture (depending on the needs) is probably what the final solution to a problem will look like.

What are the problems?

The amount of data is growing at an exponential rate and a relational database (like MySQL) is not really a distributed solution. Even though reads can be performed on slaves, writes most likely have to be done on the master (where would the consistency be otherwise?) which becomes a bottleneck in a transaction intensive system.

Relational models are rather statics and once the model has been defined you better not have to change it. From my personal experience I can say that adding a column to a table that gets 10 millions (roughly) extra rows a day without downtime is a rather complex and costly (just in the human resources involved) operation. And when you need to keep 5 years of data in that same table (which would be 18.3 billions rows) and still have a good performance on reads and writes, it gets even more complex.

When you need to store – as fast as possible – large quantities of data which structure has to be somehow flexible you’ll definitely have to have a look at the following solutions.

What are the solutions?

There are 4 kinds of NoSQL models at the moment:

  1. key/value
  2. column
  3. document
  4. graph

Key/value stores design is domain driven. Entities that are tightly coupled go to the same bucket (a customer and her shopping cart for instance) but different instances (customer A and customer B) don’t have to be in the same bucket.
With a key/value store like Redis a throughput of 110,000 database operations per second can be achieved when MySQL shows a good 15,000 (good because it’s still pretty good).

Most key-value stores provide an indexing mechanism and/or a search engine usually based on Lucene, Solr, Elastic Search.

As for the other solutions we can mention Cassandra (from Facebook), Google BigTable and Hadoop HBase (column models), CouchDB and MongoDB (document model) and Neo4J (graph database).

Graph models seems like a pretty interesting topic (even though performance is not what you can expect from a key/value store for instance) and I will definitely have a closer look at Neo4J.

high performance web sites, with ads [aftonbladet.se]

Today was the first day of the disruptive code conference in Stockholm (#dcode on Twitter) and I’m taking notes, a lot of notes. I unfortunately don’t have time to blog live from the event – too busy listening to some really good talks – so I am taking another approach: for the next couple of days, I’ll write about the sessions I have been attending.

Let’s get started then with notes I took during a session ran by Tobias Järlund, CTO at AftonBladet, the biggest Swedish newspaper (so he claims at least) : high performance web sites, with ads (don’t let third parties make you slow) which was based on AftonBladet’s experience and experiments on web site, embedding third party ads, optimization.

Facts and figures

www.aftonbladet.se lately (due to the elections in Sweden) had all time high traffic with 2.4 millions visitors a day on its front page which, as it has always been, is really, really, … really long and contains no less than 20 advertising spots.

Web performance optimization, iframes vs. JavaScript

“The server side is not the bottleneck” and, according to Tobias, optimization should rather be performed on the client side.

There are plenty of solutions available (iframes and/or JavaScript based) and AftonBladet decided, after evaluating the pros and cons of some of them, to go for friendly iframes that have the following “properties” (but not only):

  • may load in parallel
  • possible to late-load
  • full access to the DOM
  • support all types of ads

The setup

  1. create an iframe to a small static cacheable HTML page from the same domain
  2. inside the iframe, use the JavaScript variable inDapIF = true to tell the ad it is loaded inside a friendly iframe
  3. inside the iframe, create a script element with the ad url as the source (load the ad just like a normal JavaScript ad)
  4. when the ad has finished loading, resize the iframe to fit the dimensions of the ad

Even if “using iframes is the best option today” to solve that kind of problems, be careful when implementing such solutions since rendering iframes is quite an expensive operation.

Tweaks

  • don’t load all ads at once, use queues or delays
  • set default sizes (1 by 1 pixel for instance) and then resize
  • try not to block the “onload” event (the page loading speed is now taken into consideration by Google for ranking)

The future

  • <frag> tag (Google Chrome) to mark a piece of code that should be loaded in parallel, not blocking (not implemented)
  • postMessage(…) implemented in all modern browsers for messaging between iframes and the main page

Results

It’s certainly pretty cool when you get the chance to try out solutions and experiment different techniques but it’s even better when you measure the impact of the changes you make on your users’ experience!

By implementing friendly iframes Aftonbladet drastically improved the loading speed of the front page (editorial content loaded at the same time or even before the ads) and readers liked it…

  • visits per week up 7%
  • page views per visit up 16%
  • “latest news” section (which used to show up really late in the rendering process) CTR (click through rate) up 35%
  • average page load time down 30%

… and the most remarkable thing being that all those changes have not had any impact on the ads CTR

Proudly powered by WordPress
Theme: Esquire by Matthew Buchanan.