EclEmma is the right tool to measure the coverage of your code and to make sure that every single line is executed properly. It has plenty of useful features from which I’ll present only the Coverage tool. In this post you will:

• see how to run your unit tests through EclEmma
• how to interpret the output of the Coverage tool

I’m using EclEmma with JUnit4 but it will run with JUnit3 too. You will find any neccessary information regarding to the installation on EclEmma site: http://eclemma.org/.

So lets take a look at an example from the source of Qt Jambi. QPair of the com.trolltech.qt package is used to hold two generic values. There are 3 methods to test: public boolean equals(Object o), public String toString() and public QPair clone().

I won’t give any detailed explanations about the test methods since the main goal of this post is to introduce EclEmma. However if you are new in unit testing too you could take a look at one of my old posts Unit testing with Qt Jambi. There are a lot of resources about unit testing but that post is directly related with the currently studied examples.

Let’s take a look at public boolean equals(Object o) which is a method to check the equality of two objects (beware, it could be very tricky!). If you can’t access the resource above, don’t worry the code is reproduced here:

    /**
     * Returns true if this pair is the same as the other pair. If any
     * of the first or second members are null the result is false regardless.
     * @param The other parameter
     * @return True if they are equal.
     */
    @Override
    public boolean equals(Object o) {
        QPair<?, ?> other = o instanceof QPair ? (QPair<?, ?>) o : null;
        if (other == null || first == null || second == null || other.first == null || other.second == null)
            return false;
        return first.equals(other.first) && second.equals(other.second);
    }

Our test case for this particular method is:

	@org.junit.Test
	public void testEquals() {
		assertTrue("qp1", qp1.equals(qp1));
		assertFalse("qp2", qp1.equals(qp2));
		assertFalse("qp3", qp1.equals(qp3));
	}

       @org.junit.Before
       public void setUp() {

               qp1 = new QPair<Integer, Integer>(3, 5);
               qp2 = new QPair<Integer, Integer>(5, 3);
               qp3 = new QPair<Integer, Boolean>(1, null);
               qp4 = new QPair<Integer, Boolean>(null, true);	
       }

While the test case is opened, from the Run menu select Coverage As > JUnit Test. The JUnit test starts and EclEmma is calculating some measurable properties of your code. Now you should see something like this:

As EclEmma finished its job you can see the coverage result of your unit test code:

and the code of the tested class too:

But some of the lines appeared in yellow instead of green, what happened? If you take a closer look to these lines EclEmma will tell you that there are some uncovered branches in your code. In this particular case we have 5, 3 on line 79 and 2 on line 81:

Lets take a look again at our test and study it carefully:

	@org.junit.Test
	public void testEquals() {
		assertTrue("qp1", qp1.equals(qp1));
		assertFalse("qp2", qp1.equals(qp2));
		assertFalse("qp3", qp1.equals(qp3));
	}

       @org.junit.Before
       public void setUp() {

               qp1 = new QPair<Integer, Integer>(3, 5);
               qp2 = new QPair<Integer, Integer>(5, 3);
               qp3 = new QPair<Integer, Boolean>(1, null);
               qp4 = new QPair<Integer, Boolean>(null, true);	
       }

Is there any assertion in our test which is running through this if:

               if (other == null || first == null || second == null || other.first == null || other.second == null)

Lets see: the expression inside if will be true iff at least one of those conditions between || is true. Our only assertion which involves null is this one:

               assertFalse("qp3", qp1.equals(qp3));

which is, obviously, won’t cover all the possible candidates in which the above if will be executed. This assertion covers exactly one case. Remember QPair(T, S), and because qp3 was constructed with (1, null) it covers:

               if (other == null || first == null || second == null || other.first == null || other.second == null)

Thanks EclEmma for pointing out this obvious mistake! After adding more assertions to cover all the possible cases you will see something like this:

All branches are covered properly! \o/

Of course this is just one from EclEmmma’s useful features. In case of big projects it is good to see how your overall coverage is forwarding, you can check that too:

As you can see we have a lots of work to do.

This was a very short but fair introduction about EclEmma’s main feature, using it on regular basis to check your unit tests functionality will save you lots of time.

Thank you for your time, comments are welcome, as always!

Just take a look at the range of IP addresses. In ideal case an IP address tends to be closer to another IP address even when adding some new addresses between, the concept of the Hilbert curve:

source: http://www.texample.net/tikz/examples/hilbert-curve/

The previous theory is highly applicable from machine point of view, but there are also plenty of theories applicable from human point of view. Maybe the most famous is the Golden Ratio or Divine Proportion:

In mathematics and the arts, two quantities are in the golden ratio if the ratio of the sum of the quantities to the larger quantity is equal to the ratio of the larger quantity to the smaller one.

=====|===
  a    b

meaning, a+b is to a as a is to b. From the machine’s point of view, nothing particularly happens, it’s just a “constant” which values is 1.6180339887… (yes, with quotes, the value of this proportion is an irrational number therefore I’m not sure about using the term “constant” when talking about irrational numbers, if you think otherwise, leave a comment below). However this “constant” is really important when talking about beauty and perfection generally. It appears in everything which is aesthetic to us, humans:

http://www.newconcept.eu/blog/apple_logo_and_the_golden_ratio

http://www.quora.com/What-are-some-fine-examples-of-golden-ratio-principles-used-in-web-design

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, … as you may have already realized, the next number in this sequence should be 55+89=144. The numbers of the Fibonacci sequence, or the Fibonacci numbers. What could be so interesting in this sequence other than describing the growth of an idealized rabbit population?
If you don’t know yet, let me show you. Divide the current and the previous number of the Fibonacci sequence above, starting from the second element, repeating infinite times:

As you may have already discovered the results of these iterations are approaching to the value of the Golden Ratio (see above, it was: 1.6180339887…).

The question is appropriate: Is there any way to apply this abstract representation of the golden ration?

Let’s take a look at the hexadecimal representation of a color “from the web”, a0ff11. Each color consist of three components, the red: a0, the green: ff and the blue component: 11. The idea is very simple: increment every component by the elements of the Fibonacci sequence.

The implementation happened in JSP, because everyone needs to know JSP!!1 currently I’m advancing in JSP.
Nothing fancy just a simple opening page to gather the required parameters, like the base color, number of color in the palette and the component which have to be modified:

<html>
<head>
<title>Color Palette Generator</title>
</head>
<body>
	<form action="generator.jsp" method="get">
		<table>
			<tr>
				<td>Base color:</td><td><input name="baseColor" type="text" /></td>
			</tr>
			<tr>
				<td>Palette size:</td><td><input name="sequence" type="number" /></td>
			</tr>
			<tr valign=top>
				<td>Component to modify:</td><td>
				<input type="checkbox" name="red" value="r" />Red
				<br/>
				<input type="checkbox" name="green" value="g" />Green
				<br/>
				<input type="checkbox" name="blue" value="b" />Blue
				<br/>
				<input type="submit" value="Generate" />
				</td>
			</tr>
		</table>
	</form>
</body>
</html>

modifying only by blue component

click to enlarge

Now some green magic:

click to enlarge

…and some red:

click to enlarge

And finally some of the colors I picked up randomly, all three modified components are rendered at once:

#2d9b27

#412c84

#24577b

d5f800

The code itself is quite simple.

<%@ page language="java" import="java.awt.Color,java.util.*"%>
<%!/* Some members of the mighty Fibonacci sequence
	 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987
	 */
	// and some of them what I found useful:

	int fib[] = { 13, 21, 34, 55, 89, 144 };

	//int fib[] = new int[] { 2, 3, 5, 8, 13, 21, 34 };
	//int fib[] = new int[] { 5, 8, 13, 21, 34, 55, 89 };

	public ArrayList generatePalette(Color baseColor, int n, String modifier) {
		ArrayList<Color> colorVector = new ArrayList<Color>();
		colorVector.add(baseColor);
		Color tmp = baseColor;
		for (int i = 0; i < n; i++) {
			tmp = generateColor(tmp, fib[i % 6], modifier);
			colorVector.add(tmp);
		}
		return colorVector;
	}

	public Color generateColor(Color color, int delta, String modifier) {
		int r = -1;
		int g = -1;
		int b = -1;

		if (modifier.equals("r")) {
			r = add(color.getRed(), delta);
			g = color.getGreen();
			b = color.getBlue();
		} else if (modifier.equals("g")) {
			r = color.getRed();
			g = add(color.getGreen(), delta);
			b = color.getBlue();
		} else if (modifier.equals("b")) {
			r = color.getRed();
			g = color.getGreen();
			b = add(color.getBlue(), delta);
		}

		return new Color(r, g, b);
	}

	public String colorToStr(Color color) {
		String r = Integer.toHexString(color.getRed());
		String g = Integer.toHexString(color.getGreen());
		String b = Integer.toHexString(color.getBlue());
		r = r.length() < 2 ? "0" + r : r;
		g = g.length() < 2 ? "0" + g : g;
		b = b.length() < 2 ? "0" + b : b;
		return r + g + b;
	}

	// if > 255 restart from 0
	public int add(int old, int d) {
		if (old + d > 255)
			return old + d - 255;
		else
			return old + d;
	}%>
<%
	String baseColor = (String) request.getParameter("baseColor");
	int colorToInt = Integer.parseInt(baseColor, 16);
	Color newColor = new Color(colorToInt);
	String sequence = (String) request.getParameter("sequence");
	int times = Integer.parseInt(sequence);
	String[] modifiers = new String[3];
	modifiers[0] = (String) request.getParameter("red");
	modifiers[1] = (String) request.getParameter("green");
	modifiers[2] = (String) request.getParameter("blue");
%>
<html>
<head>
<title>Color Sequence Generator</title>
<link rel=stylesheet type="text/css" href="generator.css">
</head>
<body>
	<%
		for (int j = 0; j < modifiers.length; j++) {
			if (modifiers[j] == null)
				continue;
	%>
	<table class="main">
		<tr>
			<%
				ArrayList palette = generatePalette(newColor, times,
							modifiers[j]);
					for (int i = 0; i < palette.size(); i++) {
						String current = colorToStr((Color) palette.get(i));
			%>
			<td class="colorDiv" bgcolor="#<%=current%>"><font
				class="colorName">#<%=current%></font></td>
			<%
				}
			%>
		</tr>
	</table>
	<%
		}
	%>
</body>
</html>

The packages in ppa should arrive soon, stay tunned.

}


tests.compile

will compile and build the required library/sources for autotests, and

tests.run

should run the tests.
Finally you can open the generated test report build/TestResults/index.html.