Mockito is back !

Mockito is back with a new release (1.10.x), after almost two years from the last official release (the well-known and loved 1.9.5).

Several 1.10 updates have come out after the 1.10.0 released at the end of this September.

Mockito 1.10.x includes several improvements and cleanups. Interesting is the possibility to create light-weight mocks and the BDD “then” support .

Release notes here.

Thanks to Szczepan Faber and the rest of the team for their wonderful job.

Tips: NetBeans on Ubuntu

Ubuntu Linux is a very nice software development platform and NetBeans fit very well in it.

Nevertheless few tips can make our developer life easier. These tips can be applied to other Linux distributions.

1. Do not use apt-get

Apt-get is the Ubuntu/Debian tool to download and install programs from the repositories.

It should not be used to install the tools you need for development, NetBeans included.

Reasons:

  • Repositories contains old versions
  • Dependencies force you to install not needed or incompatible software

Get installation files from the main sources and install them manually in a common dir like /opt.

2. Install NetBeans on a user writable dir

NetBeans needs to update files in its own installation directory during software updates. I suggest to use /opt as the main installation dir.

If /opt is now user writable, execute the following command

sudo chmod 777 /opt

3. Watch the /tmp size

NetBeans use /tmp for temporary operations like, for example, updating Central Maven repository information. While doing this update, NetBeans saves big temporary dirs under /tmp and the update fails if /tmp has no space available.

The /tmp dir is usually small when it is mounted on a dedicated partition.

Reserve at least 1.5GByte free space on the /tmp.

See Bug 162313 for more details.

4. Save NetBeans cache in RAM

NetBeans saves configuration, user preferences and project files status in the NetBeans user dir which is located in $HOME/.netbeans/<version>.

Part of this information, mainly related to projects is considered to be a cache (= it can be recreated if deleted); the cache can be located in a separated dir with the command line –cachedir.

With at least 4 GByte RAM, we can map the cache dir to a temporary RAM on disk using Ubuntu native ram filesystem.

My preferred approach is to

- mount the /tmp to a tmpfs type filesystem, by adding the following line in the /etc/fstab

tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=2048M 0 0

This will “map” the /tmp dir into RAM up to 2GByte (see tip #3).

- map the cachedir to a /tmp/ subdir, by creating a NetBeans invocation script as the following:

#!/bin/sh
export VERSION=netbeans-8.0.1
export RAMDISK=/tmp/$VERSION
export OPTIONS=" --cachedir $RAMDISK --laf Nimbus "
/opt/$VERSION/bin/netbeans $OPTIONS &

The script will invoke NetBeans with the appropriate options.

Note: I like Nimbus on Ubuntu Unity user interface.

5. Use a SSD drive

SSD drives are an impressive speed improvement. Software development requires reading and writing hundred of files. Speed is essential to have quick feedback during our test and compilations cycles.

The SSD drive can be your main hard drive or an external one (possibly on a fast USB connections). Just place both NetBeans installation dir and your projects files on the SSD unit.

Remember to add noatime option on the mount instructions (see /etc/fstab) to avoid useless write access to the disk.

Review: Mastering Unit Testing Using Mockito and Junit

Mastering Unit Testing Using Mockito and Junit
Mastering Unit Testing Using Mockito and Junit by Sujoy Acharya
My rating: 4 of 5 stars

Good reading. A complete picture on unit testing across applications layers and frameworks.

The author covers all topics related to unit testing Java based applications using jUnit at several application layers (data, business, web), starting from project setup (using Eclipse, ant, maven, gradle and even jenkins) and ending to tests creation best practices.

Even test beginners can benefit for this book because all explanations are clear and complete.

First four chapters explore unit testing concepts by means of jUnit and Mockito libraries.

Chapter five is dedicated to code coverage using both Eclipse plugins and command line tools (via ant, maven and gradle)

There is also a chapter (#6) dedicated to static code analysys with FindBus, PMD and SonrQube.

Remaining chapters are on web (#7) and data (#8) layers testing, on legacy code testing issues (#9) and, finally, on test best practices (#10).

View all my reviews

New Java releases: 8u20 and 7u67

 JDK 8

After the 8u11 release on mid of July, Oracle has released JDK 8u20 which includes several new and updated tools and a significant amount of bug fixes.

Java Mission Control has been updated to version 5.4. JMC is a tool to monitor and collect data from running applications and Java run-time environments.

AMC (Advanced Management Console) is a Java applications and versions usage collector and analysis tool. It requires a commercial license.

Another commercial product is the new JRE installer for Windows which fully support MSI technology.

Nice feature for 64bit users is in the Java Control Panel where we can select to automatically update  both 32bit and 64bit JRE.

Complete release notes can be found at http://www.oracle.com/technetwork/java/javase/8u20-relnotes-2257729.html

Bug fixes: http://www.oracle.com/technetwork/java/javase/2col/8u20-bugfixes-2257730.html

By the way, the famous Java 8 bugs which affected several third party tools like jRebel (see for example http://www.infoq.com/news/2014/08/Java8-U11-Broke-Tools) has been fixed. See https://bugs.openjdk.java.net/browse/JDK-8051012 for details.

JDK 7

New update also for Java version 7: 7u67. This version only includes the bug fix for the verifier regression (see above).

Complete release notes can be found at  http://www.oracle.com/technetwork/java/javase/7u67-relnotes-2251330.html

JDK 6
Java 6 and previous versions are at end of life stage so they are no more updated.

Review: Mockito Cookbook

Mockito Cookbook
Mockito Cookbook by Marcin Grzejszczak
My rating: 5 of 5 stars

Very good. This is a well written and very interesting reading for everybody involved in Java testing. This book is not intended to be a primer on testing in general and on Mockito in particular. Beginners should look for an introduction on automated testing before start with Mockito Cookbook. The author covers everything related to the Mockito library and also on several additional libraries and tools connected to Mockito, like, for example, PowerMock. The book starts with an introductive chapter on Mockito installation and basic usage with both JUnit and TestNG. The core of the book is the chapters from 2 to 7 where the author explain, as recipes, several techniques to test easy and difficult to test code. Final book chapters are on legacy code testing, testing using frameworks like Spring and Mockito compared to other mocking libraries. In all examples, sometimes a bit repetitive due to the recipes approach, the author also explain general testing and object oriented programming approaches and methodologies. This is of course limited in space but there are plenty of references.

View all my reviews

My 5 favorite NetBeans IDE features (vs. Eclipse)

In my current project, Eclipse Kepler has been selected by the customer as the preferred IDE for all main tasks. Of course, I’m also using NetBeans 8.0 for some activities like, for example, legacy code test coding.

I have already used Eclipse some years ago and, at that time (2009), Eclipse Galileo were quite superior to NetBeans 6.x: faster, rich of code hints and warnings, full of useful plugins. So, I was not really happy when the project moved to NetBeans (because of its Swing support).

Now let me compare them again, Eclipse Kepler 4.3 vs NetBeans 8.0, on same project (a big ant based web project) and on the same PC (Win7 64bit 4G RAM).

Speed

My first big surprise. Five years ago, when I moved from Galileo to NetBeans I really missed Eclipse speed: coding, windowing, compilation, everything were significantly faster in Eclipse.

Now this speed advantage is gone. I don’t have benchmarks to demonstrate my feeling but now my coding is visibly faster with NetBeans 8.0 than with Eclipse Kepler. If you install Findbugs and PMD plugins, Eclipse becomes really slow.

Native testing support

Second surprise. Why, in 2014, an IDE for Java EE developers does not include full testing support ?

I cannot imagine any real EE developers which does not need any kind of test support from the IDE.

In NetBeans there is complete native jUnit and TestNG support (templates, test runs, jump to test option in the editor, both *Test and *IT files support) which I found very useful and efficient.

Eclipse native support is poor but of course it can be extended via plugin. I’m using MoreUnit plugin which is quite nice and add many missing features to Eclipse. See here for a small tutorial.

But even if you install a test support plugin like MoreUnit, still an important Eclipse limitation remains : the possibility to have a dir for test files separated from the main src dir, which is an essential feature to let us handling deployments. If you don’t believe me, have a look at this 2008 bug still open: https://bugs.eclipse.org/bugs/show_bug.cgi?id=224708 and its related bugs.
Simply unbelievable.

Java Hints and FindBugs integration

While coding, it is important to have feedbacks from the IDE about the quality of the code and possible errors. NetBeans Java hints is a very reach set of the code checks which helps me to avoid stupid errors and keep high the quality of my work. In addition, NetBeans includes first class support for FindBugs which, again, helps me during coding sessions.

I’ve found NetBeans code quality checks support better than the one available in Eclipse Kepler + FindBugs plugin. More checks and better control on how, for example, disable a FindBugs warning on a line (because it is ok) using an annotation: just a click with NetBeans and by hand with Eclipse.

Coding support: templating, completion,interfaces…

I like NetBeans coding support: code templates (some letters + tab to get most used keywords and structures (see here for some examples), auto-completion, now also using sub words, I can easily jump from an interface to its implementation, the new indent guide lines.

Similar features are available in Eclipse using, for example, the Code Recommenders plugin but I’ve found it quite slow on my machine so I had to disinstall it.

User Interface

NetBeans user interfaces has improved a lot while keeping its strong point: it is easy to use. Windows and menus are easy to find and the full screen mode is very useful on small screens. I really like the color coding setup (Norway Today) which makes code reading a pleasure and the dark skins for working late in the evening.

On the contrary, Eclipse interfaces remains somehow confusing and, my personal opinio, perspectives and workspaces are simply a waste of time.

Tutorial: unit testing in Eclipse with moreUnit plugin

Eclipse Kepler, even in the Java EE Developers edition, does not include a good enough support for automatic tests development. Both NetBeans and IntelliJ have superior native support for testing. For example, if you rename one class, Eclipse does not rename its test class.

To overcome such limitations, we need to install a plugin.

In this tutorial, I will describe moreUnit (http://moreunit.sourceforge.net/), a plugin which extends Eclipse testing support. I will not cover moreUnit installation because it is quite standard.

Let’s create a standard ant based Eclipse project. In the example the project name is “EclipseTest” and the main package is “it.gualtierotesta”.
20140522_01
In the package, I’ve created a new Java class named MyClass with the following content:

package it.gualtierotesta;

public class MyClass {

    private String msg;

    public String message() {
        return generateMsg();
     }

    private String generateMsg() {
        return "Hello " + msg;
    }

    public String getMsg() {
        return msg;
     }

    public void setMsg(String msg) {
       this.msg = msg;
    }

}

Very simple. We want now to create a unit test to check the message() method. While in the Java Editor window, you should press Ctrl+R (or, from the contextual menu, MoreUnit –> Jump To Test) to trigger test class creation.

20140522_02
where we can select our preferred unit library. In this tutorial we will use JUnit 4.

Press “Finish” to confirm. Note: Eclipse will eventually ask you to add JUnit library to the project build path.

In the created test class (MyClassTest.java file), add the following contents:

package it.gualtierotesta;

import org.junit.Assert;
import org.junit.Test;

public class MyClassTest {

@Test
 public void showMessage() {
     // given
     MyClass sut = new MyClass();
     sut.setMsg("Gualtiero");
     // when
     String res = sut.message();
     // then
    Assert.assertEquals("", res);
 }

}

Note: sut is system under test.

In the test class window, press Ctrl+R to run the test. Test will fail:
20140522_03This is expected because the Assert.assertEquals check for the wrong result.
Change the Assert line as following:

Assert.assertEquals("Hello Gualtiero", res);

E re-run the test (Ctrl+R). Test will now succeed.
20140522_04
Note: in the test method body I added some comment lines to divide the body instructions in three sections. Given section is where the test texture is prepared, when is the execution of the method under test and the then section marks the results checks instructions (assertions). This is a good habit to make test strategy clearer. It comes from BDD, Behavior Driven Development (http://en.wikipedia.org/wiki/Behavior-driven_development).

 

A nice moreUnit feature is to mark the Java source file icon with a small green rectangle to show that the class has a test class.
20140522_05We have now our test running without failure but still our setup is not correct: test classes should be placed in a different source folder because they should not be packaged and released to the user.

Traditional approach is to have src dir for Java source files and test dir for test classes.

We create now a new folder named “test” under project root:
20140522_06
Then in the Java Build Path section of the project properties we add the new test folder as one of the project source folders:
20140522_07
Finally we configure moreUnit to use the “test” folder as the place to create and look for test classes:
20140522_08
Finally we can move the MyClassTest.java to the test folder (or create it again).

At the end, the project configuration is the following:
20140522_09As shown in this short tutorial, moreUnit plugin simplify a lot test classes handling in Eclipse.

Moreover, moreUnit offers special support for mocking libraries users. The test class creation wizard has additional pages to insert mocking specific instructions in the test class:
20140522_10
In this page, you can select the dependencies you want to mock and moreUnit will add specific mocking instructions. For more info about Mockito, have look here and here.