Tag Archives: Java

EclEmma: the free Java code coverage tool for Eclipse

Unit testing has a lot of aspects which are more or less equally important but code coverage is something on what you really have to pay attention. Depending on the complexity of our methods, more combinations are possible on arbitrary test inputs. Considering every permutation in some not-so-obvious cases takes some time and effort, and the chance to make a mistake – which will result in an uncovered piece of code – is even higher.

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!

Advertisements

Building Qt Jambi 4.7 on Ubuntu 10.04

NOTE: This is an Ubuntu-only tutorial. Some parts of it may not work on other Linux distributions. For the general building documentation visit: http://qtjambi.sourceforge.net/development/building/.

Finally I’ve managed to compile the latest version of Qt-Jambi framework, here I’ll share with you my build-experiences and highlight the points where you can break something.
There is also a Building document on the official website of Qt-Jambi, what gives an overview about building on several platforms, here I’ll focus to Ubuntu 10.04.
Grab the latest version from git, because the development happens here. Type in Terminal:

git clone git://gitorious.org/qt-jambi/qtjambi-4_7.git

Important: always check it twice before cloning, there are more qt-jambi repositories hosted at http://qt.gitorious.org/, but with the given build dependencies just this one compiles – eventually the trolltech one if you compile it against system Qt.
The URL after gitorious.org/qt-jambi/ will be change from time-to-time, you can make sure that you have typed the right URL by navigating to the community git repository of Qt-Jambi, and copying the URL from Clone & push urls.

Assuming that you are using Ubuntu 10.04 so you don’t need the kde-phonon backend. The list of dependencies is:

  • For Qt-Jambi:
  • openjdk-6-jdk (or alternatively the sun-java-jdk)
    ant-optional
    ant
    libxext-dev
    libgstreamer-plugins-base0.10-dev
    libgstreamer0.10-dev
    build-essential
    chrpath
    libgtk2.0-dev
    libexpat1-dev
    libfontconfig1-dev
    libfreetype6-dev
    libpng12-dev
    libcups2-dev
    libgtk2.0-dev
    libssl-dev
    libasound2-dev
    libdbus-qt-1-dev

  • For Qt itself:
  • phonon-backend-gstreamer
    libqt4-dev
    libphonon-dev

    You can install these from synaptic or copy/paste to the Terminal:

    sudo apt-get install openjdk-6-jdk ant-optional ant libxext-dev libgstreamer-plugins-base0.10-dev libgstreamer0.10-dev build-essential chrpath libgtk2.0-dev libexpat1-dev libfontconfig1-dev libfreetype6-dev libpng12-dev libcups2-dev libgtk2.0-dev libssl-dev libasound2-dev libdbus-qt-1-dev phonon-backend-gstreamer libqt4-dev libphonon-dev

    After cloning the repository and downloading the build dependencies go to the root directory of the cloned repository.
    In the Terminal session where you have checked out the git clone type:

    cd qtjambi-4_7

    If you have installed the libqt4-dev through the package management system then you don’t need to change anything.
    If you have your own compiled version of Qt then modify the variables qt.libdir, qt.includedir, qt.pluginsdir in buildpath.properties according to your Qt installation.

    Modify the version.properties file according to your Qt version (take a look to aptitude show libqt4-dev).

    Add the following environment variables to your ~/.bashrc file:

    #QTDIR bin
    PATH=/usr/share/qt4/bin:$PATH
    export PATH

    #set for Qt home
    QTDIR=/usr/share/qt4
    export QTDIR

    #set for Qt Libraries, usually QTDIR/bin
    LD_LIBRARY_PATH=/usr/share/qt4/lib
    export LD_LIBRARY_PATH

    #set for Java home (the exact path depends on your Java version)
    JAVA_HOME=/usr/lib/jvm/java-6-sun-1.6.0.20
    export JAVA_HOME

    Restart the Terminal to apply the new environment variables, and in the directory qtjambi-4_7 type:
    ant all
    .

    When the build finished you can try running the Qt-Jambi demo program, by typing:

    java -cp "qtjambi-4.6.2.jar:qtjambi-linux32-gcc-4.6.2.jar:qtjambi-util-4.6.2.jar:qtjambi-examples-4.6.2.jar:qtjambi-designer-4.6.2.jar" com.trolltech.launcher.Launcher
    .
    If you have any questions or errors during the building, please drop a comment or take a look to #qtjambi IRC channel on irc.freenode.org.

    Happy hacking.

    YAMI stalled

    Hi!

    Just came back from Croatia/Njivice, it was fun and I’ll post some pictures here as soon as I can!

    http://yami.googlecode.com

    This is my first project in Java, started just for fun and to learn some advanced gui/jdbc programming.
    By default it’s a browser for MySQL databases, but I implemented a mysql-console-like interface for cmd lovers (You can see some screenshots on the site, or download it, checkout on svn, etc…).
    I planned to improve it by allowing the users to create/modify the existing databases/tables.
    Because I’m the only developer of this project (of course you can join at any time! ) it takes a lot of time to implement such things.
    Does it worth to continue with my plans and to improve this project?
    What do you think?