Using AssertJ

AssertJ ( is an assertion library which can be used to improve our test units code.

I’ve found two significant benefits by using this library compared to other solutions I used (jUnit basic assertions, Hamcrest and Fest Assert 1.x).

First, its fluent interface (same as Fest Assert) let me express in a more compact and readable way the assertions.

For example, assuming list is a java.util.List, the following jUnit asserts

assertEquals(3, list.size());

can be replaced by


which I believe it is a more readable and compact code.

Second benefit is the wide range of checks we can do without need for conversion methods or additional libraries. For example, assuming birthday and aDate are java.util.Date instances:

// check if birthday is today
// check if aDate is Aug 8th, 2013

or, assuming aMap is a java.util.Map,

// check if aMap has all 3 keys
assertThat(aMap).containsKeys(key1, key2, key3);

Again we can have more readable and compact code but also we can be more specific and correct in our assertions.

In the AssertJ web site (hosted on GitHub) you can find the usual API documentation ( but also a good source of examples in where you can get syntax and examples for your assertions.

Maven users can add AssertJ as test dependency


Utility functions in JavaScript

We often have JavaScript functions which are used in several pages of our project. Best approach is to store all these functions in a shared JavaScript file, included when necessary.

The usual approach I adopt (and suggest) is to create an utility class like the following one:

function Util () {} = function (sel) {
    return jQuery(sel).val();

Util.write = function (sel, val) {

We start to define an empty Class (named Util) by a constructor and then we add to it our functions.
These are “static” like functions which are always available, without the need to create an instance of the class Util (with the new operator).

I save the above code in a util.js file (file name = class name).

How to use the utility functions ?

    // read the value of the element with id myinput
    var val ='#myinput');

JSLint users: don’t forget to add Util in the globals list ( /*globals Util */ )

Final comment: these approach should be used only for utility methods which do not save internal state
or use global variables. The constructor function should be empty; the functions defined as above (and not via class prototype) cannot access to any
class field.

Improving Web pages [1]

Many Web standards (HTML, CSS, Javascript) allow us to be very free in organizing the files internal structure and their relative position inside our web projects.

Unfortunately this freedom can create situations which are not only difficult to manage in the mid and long terms but also they may work worst than better organized equivalents.

There are few rules which we can follow to improve the quality and, at the same time, the performances of our projects.

The first simple rule is the following:

  • Keep Html in .htm / .html files
  • Keep CSS rules in .css files
  • Keep Javascript code in .js files

Or, in other words, do not embed CSS and Javascript inside HTML (as much as possible, of course).

This strategy creates files with clear meaning and contents.

There are several advantages:

  • Pages download is faster because browser can easily cache Javascript and CSS if they are on external (and stable) files. Caching is not possible if Javascript is inside the HTML page.
  • Development is easier thanks to the support of HTML editor and IDE like, for example, recent Netbeans 7.3.
  • Pages are easier to update, even by other programmer, because of clearer structure.

The internal structure of a HTML page could be like the following

<!DOCTYPE html>
    <link rel="stylesheet" type="text/css" href="/css/style.css">
    .... contents....
    <script src="/js/script.js"></script>

In the code above, the CSS rules have been placed in the style.css which is in the css dir. The css dir will contain all our CSS files.

The CSS files should be included with a link tag inside the head tag. Note: the head tag usually contains other information not included in this fragment.

The Javascript code is inside the external script.js file which is in the js dir. The js dir will contains all our Javascript files. Please note that it is not necessary to specify the language or the type in the script tag.

Our project will often use Javascript and CSS files from third party libraries (like jQuery and Bootstrap). In this case it is useful to keep them in a separate dir like /ext/<name> where <name> is the name of the library. Inside it, the files position is usually defined by the library author.

The target is to keep our project structure clean and clear; the /ext contains everything which has not been created by us.

A final but very important remark: the script tag(s) in a page should be placed at the very end of the body tag. Not at body tag begin, nor inside head tag.

Reason is simple: let the browser download all HTML before start to work on Javascript code. The browser can start to create the DOM structure and render (= show to user) the page before executing Javascript code that, in most of the cases, is referring any way to elements in the page. Specifying the Javascript code at the begin of the page is simply delaying rendering phase without any benefit.