Mutation testing with PIT

How can we know that our unit tests are good?

Code coverage can't say that we have proper unit tests - it's just a side effect of using TDD.
It says what code has been executed in the unit test - we can write a test which just executes a method and without any assertions we'll have 100% code coverage.

Let's take a look at the following class:

It's a simple class that tells us if a given number is higher or equal to zero.

Let's take a look at the unit test:


When we execute cobertura on this test, we will see 100% coverage, both line and branch, even though it forgets about the case where the number is 0.

Mutation testing is an idea that tries to measure the quality of unit tests. They are run against modified version of the source code (by applying various mutators - hence the name). If the application code is changed, it should produce different result, therefore the unit test should fail. If it doesn't fail, it may indicate problem in the test suite.

PIT (http://pitest.org/) is a bytecode mutation testing system that automatically applies mutators to the application code.

If we run it against above mentioned class, it will produce a nice HTML report saying that 'changed conditional boundary' has survived - which means that we didn't test all boundary conditions.

We can integrate execution of PIT into our build (there are plugins for maven, ant and gradle) or we can execute it within our IDE (plugins for Eclipse and IntelliJ - that one I've created recently).

The project is actively developed, so we can expect more features to come.

JUnit - hamcrest incompatibility

When we're using the latest version of JUnit (4.10) and hamcrest (1.3) together we might come across an unexpected behaviour.

Let's take a look at a simple test:

We might think that this test will fail because of the assertion, but the result is:

java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V

That's because the default JUnit has a dependency to hamcrest 1.1 and also the artifact org.junit:junit has some hamcrest classes inside its jar. The hasSize matcher is not present in 1.1.

To avoid this problem we need to declare following dependencies in our project:

We need to use JUnit distribution that doesn't have any hamcrest internals and we need to exclude hamcrest dependency as well. What's interesting, we will not bump into this behaviour unless our assertion throws an error. 

Manipulating collections with lambdaj

Java is not that nice regarding manipulations on collections even though tasks like iterating happen to us on a daily basis.

To ease the pain a little bit we can use the lambdaj library that allows manipulating collections without using loops.

Here is a simple unit test that shows some of lambdaj API and features
(Person class is a pojo with age and name fields, and implemented hashCode and equals methods):


As you can see the code using lambdaj is much shorter and more readable.

The features of the library go far beyond that, there are many aggregation and filtering functions, as well as grouping, sorting and possibility to invoke a method for each collection's item.

The main drawback is that it's slower than standard iterative approach, so if speed is your concern, you need to watch out. However you can always use it in the unit tests.

Extending maven with some groovy magic

Maven is very strict regarding its conventions and the build lifecycle. Even though it has a lot of plugins that extend its functionality, it doesn't always do what we want it to do.
(If you want more freedom take a look at gradle)

Writing our own plugin is time consuming but we can easily extend maven capabilities with executing groovy code during the build.
All we need to do is add gmaven plugin into pom.xml.
Let's see an example that will make our maven build tell us which operating system we are using:

When we add the plugin we need to specify in which phase it will be run ('validate') and which goal of the plugin will be invoked ('execute'). Then in the source section we write our groovy code that will be executed. As you can see we have access to the dependencies declared in dependencies section of the pom file.

If we don't want to inline our script we can specify the file that contains it:

Another interesting feature is access to maven variables that can be used in the xml configuration of the build.

The findbugsSettingsDirectory variable is set inside our script and then used in the configuration of findbugs plugin.

Testing legacy code with Mockito spies

When we're working with legacy code, before making any changes we should write unit tests that will prevent us from breaking existing functionality. However most of the time, writing tests for legacy code is not easy.

Let's take a look at a simple example, that will try to show the challenges that we may face:

We have a class that calculates a discount for a customer based on his name and the amount of product that he's buying.

The problem hides in a static method call CustomerService.isImportantCustomer(). In the old code we can see a lot of static methods. Let's say that the one in our example is calling the database.
We need to mock it in order to write a proper unit test.

First of all, we will extract the static call to a separate method:

Refactoring using IDE (extracting methods, renaming etc.) is considered to be safe. Once we did that we can use a nice feature of Mockito - spies. 
If we declare our tested class as a spy, we can mock its method the same way as with standard mocks. The test for our class could look like:

The Mockito API for spies is similar to the one for mocks (the syntax is different for overriding void methods).

Testing getters and setters with openpojo

Testing getters and setters is a little bit controversial topic. However, if we decide to do it or if we are forced to, we can ease the task with openpojo library.

Generally standard getters and setters can be generated by your IDE but testing them is a manual work - it takes some time and seems to be boring. So if the code was generated, why can't we automate the testing?
openpojo doesn't generate the unit test but it allows to test your POJO with a very small effort.

Let's take a look at an example. We have a Person class which is a POJO with generated getters and setters.


To test it we need to create just one class:

Our class defines which rules openpojo will apply and what tests it will execute. We also specify which package will be tested - if we have a lot of classes we can test them all in one go. In our case we're only testing if  getters and setters exist and if they behaving in a conventional way.
Running the class with any coverage tool will show us that the get and set methods are executed.
There are more rules that we can apply (like checking if there are no public fields, no primitive values etc.). We can write our own rules as well.

JMS with Spring configured in Java

Handling JMS using standard JMS API is a tedious task - you need to create a lot of boilerplate code.
Spring provides an abstraction layer that eases this pain.
In the following example I'm using ActiveMQ (which needs to be started before running any of the code below) but Spring works with other major JMS implementations as well.

In order to send a JMS message we can use JMS template. Here's our sender that's using it:


Spring beans needs to be configured in a context. Let's define Spring configuration in Java code:


JMS template must have a connection factory with a broker url and a destination (in our case it's a queue).
The XML configuration equivalent would look like:


Java configuration provides not only compile-time checking but in my opinion it is more straightforward and easier to control.
Unfortunately we can't escape XML completely, we need to turn on component scanning so that Spring will read configuration from classes in our package:


The example code that would run the sender:

Apart from the sender we can also create the receiver. One of the solutions is to make him asynchronous by implementing MessageListener interface.


The Spring config looks as follows:


Our receiver is set in the message listener container with the connection factory and the destination.
Receiver is missing the same XML configuration as sender, and the running code is analogical.

Here's the list of maven dependencies:

Testing asynchronous calls with awaitility

Testing asynchronous systems is not an easy task. Let's take a simple example:


We have a class that creates file based on a given file name. The interesting thing is, that it does it asynchronously using a thread pool and returns immediately to the caller.

Let's try to create a test for it. Our first attempt could look like that:


The horrible thing about it is that Thread.sleep() invocation. Test should be fast, making them wait unnecessary is very poor solution. And what if the test sometimes fails because of overloaded hardware? Are we going to sleep even more?

To eliminate unneeded waiting, we may come up with a concept of validator:


We no longer need to sleep for a long time, but the code has been significantly polluted. Of course we can refactor our validator, make it more reusable but why reinvent the wheel? There is a nice and small library - awaitility - that will do the same for us.


In a very expressive way, we achieve the same result. Timeout, polling delay and polling interval are of course configurable.

logback - successor of log4j

The old and good known log4j seems to be a standard framework for logging in Java applications, despite some serious disadvantages like boilerplate configuration, lack of good documentation and overcomplicated architecture.

The authors of log4j dispatched on another journey and created its successor - logback, which addresses old problems and adds a lot of enhancements. 

Configuration is now more concise (it can be even written in groovy) and well documented.
slf4j api is used natively, so the implementation can be changed easily.
The issue with many instances of RollingFileAppender writing to the same file was also resolved.

In order to add logback to your project you need to add two dependencies:

You're basically ready to go, because default configuration is applied, when no other is found.

When following class is run:


it will print something like this:

But the coolest feature is automatic reloading of configuration file.

When we add this example configuration (saved as logback.xml) to the classpath:

we can change it on the fly and logback will automatically apply changes (at configured interval, in our case 5 seconds) without a need to restart the application.

Getting result from thread's execution with Future

To make things go faster we parallelize our computations. What if we need to use the result of the thread's execution?
Let's say we have a service that buys some product. It needs to fetch the price and quantity of the product. Fetching the price usually takes longer, so we delegate this task to a thread, while we are dealing with quantity.
To keep things simple, our PriceChecker class will be just simulating that it does something meaningful:

Now it would be good to somehow get the result of checkPrice() invocation. Runnable's run() is a void method, so we would have to do something like this:

This approach has a lot of drawbacks. We have to check in the loop if the price has already been set. What is more, price cannot be a final variable but has to be a field instead.

To deal with this kind of a problem, the Future interface should be used. Basically, it allows to get the result of thread's execution. Let's take a look at the actual usage in the context of our example:
First of all we're using Callable which is similar to Runnable but is capable of returning the result. Notice that it can also throw exception, while run() cannot. When we submit the callable to executor service, we're getting the Future object. Its method get() blocks until the computation is finished. If we want to specify the maximum time that we want to wait, there is an overloaded version that takes waiting time settings as parameters.

The runner for both cases is pretty straightforward:

Handling read and write operations on shared object

Many times we come across a problem, when in the multithreaded environment some shared object has frequent read operations and write operations are rare. If we could use a concurrent collection that would be the best option in most of the cases, but sometimes we can't.

Let's imagine a situation when this shared object is in a 3rd party library. In our example this object is a Book class that I used in previous posts.

Most of the time we want to show information about the book, but exceptionally the author modifies the content and therefore the number of pages needs to be changed.

Using synchronized for the methods that read/write the book would be a poor solution.
Instead, we could use ReadWriteLock which allows to differentiate between read and write operations. Read operation is concurrent, which means that all the threads have access to the object. Only write operation is exclusive and blocks other threads.

Everything we do after acquiring the lock must be put in a try block, so that unlocking is done even if the exception is thrown.

Let's see it in action:

We have 10 threads that are performing 100 tasks. Only 10% of them are write tasks. When we run it, we can see that read operations are concurrent (lines about the reading thread and book info are mixed from time to time) and write operations are exclusive (info about writing thread and successful update are always in the correct order).

The example with the book is purely educational and not too realistic. In real life we would probably have some kind of a large collection. It's good to read ReentrantReadWriteLock and ReadWriteLock javadoc, because sometimes using them may bring more overhead than mutual exclusion.

Overriding equals and hashCode with Guava and Objects class

We usually use IDE to override equals and hashCode methods in our classes.
Let's see how IntelliJ IDEA 11 copes with a simple class with 3 fields:
Even though the class seems simple, the methods' size is a little bit scary.
Using EqualsBuilder and HashCodeBuilder from Apache Commons Lang makes the methods much smaller, however introduces one major flaw: it uses reflection, which isn't a speed demon.
To the rescue comes Guava, which makes these methods simpler and more readable:
If you're working on a project in which you can use Java 7, it provides a similar solution without having to use any external library:
At the time of writing this, IDEA 11 doesn't support generating equals and hashCode using Guava or Objects class from Java 7. I created a plugin that provides such possibility:
http://plugins.intellij.net/plugin/?idea&id=6875

Coordinating threads

In our multithreaded application we may need to coordinate the work of our threads. The most occurring situation is waiting for all the threads once they finish their work.

Let's take a simple example: we have 2 threads that are doing some mathematical operations and we need to wait for both of them before we proceed with further processing. We could do that using thread's join() method:

If the number of threads is higher, this implementation will look much more nastier, as we would need to invoke join() method on all of them.


That's why the better solution is to use CountDownLatch, "that allows one or more threads to wait until a set of operations being performed in other threads completes", as Javadoc says.

In the constructor of CountDownLatch we specify a count - as each of our threads will be doing only one countdown once work is finished, it is equal to the number of threads. await() method makes the current thread to stop, until latch has counted down to zero. It also provides possibility to wait for the specified time.

If threads must repeatedly count down in a similar way, we would need to use CyclicBarrier instead.  

Concurrent map with timed out elements using Guava library

Sometimes we have a need to use a map, in which elements live only for a specified amount of time.
We could implement such map ourselves (by overriding removeEldestEntry() from LinkedHashMap or using thread that will be removing elements periodically) but the better idea is to use already existing implementation. Google's guava library (http://code.google.com/p/guava-libraries) is the solution for us.
Let's write some simple unit tests to check the API and verify behaviour:
Map is created using the builder pattern. Apart from specifying the time of elements expiration, it allows among others, setting the maximum map's size or the listener that will be notified each time an entry is removed. As the built object is an instance of Cache, we need to create ConcurrentMap from it using asMap() method.
Two tests verify that added element is removed only when the timeout expires.

Concurrent collections

As I already mentioned, situation that requires concurrent access to a collection is pretty often. Let's say that we have a map that is accessed by many threads.
Synchronizing it like this is not the best choice, as only one thread at a time will be able to access it.
Another approach is useful only in a few cases. The factory method creates synchronized wrapper for our map that makes it thread-safe. However if we want to iterate over it, we still need a synchronization, otherwise it will throw ConcurrentModificationException when some other thread will modify it while we're iterating.

The better solution is to use ConcurrentMap  It not only gives us a concurrent access, but we can also iterate over it without synchronization.

Let's imagine a situation that we need to put some value to the map, on a condition that it isn't there already.
Doing it that way is a wrong solution: After we check that the key is not there, another thread could put some entry to the map and we will override existing value. Basically our operation in this implementation is not atomic.
So should we add the synchronization? No, the ConcurrentMap provides a method that will make this operation atomic:

ConcurrentMap provides also other methods that are able to perform atomic replacement or removal of an entry, only if it is mapped to a specified value.
There are also a concurrent implementations of List and Set - CopyOnWriteArrayList and CopyOnWriteArraySet. Every mutative operation on them creates a new copy, so they should be used with a special care. 

Blocking queues

It happens that in our system's architecture we have a situation of concurrent access to some collection. Whether it's a server that handles requests via sockets or a JMS listener, it usually stores incoming objects into a collection and other worker processes them. It can be illustrated as a well known producer-consumer problem.

An example implementation could look like that:
We have a class that serves as our producer. In an endless loop we're sending random strings to a queue. Access to it is synchronized by acquiring its monitor. We're sleeping 1 ms so that the processor is not over-killed.

Let's take a look at a consumer: It synchronizes queue in a similar way. What is more, before taking from the queue, it checks if it's not empty. It also sleeps 1 ms for the same reason as producer.

Class that glues them together:

We're using LinkedList as an implementation of our Queue. Producer and consumer are started in a separate threads.

There are at least 3 major drawbacks with this implementation.
First of all we're acquiring monitor of the queue, so we're completely blocking access to it not allowing for a concurrent access.
Secondly we need to check if the queue is not empty before taking from it.
Last but not least, consumer sleeps some specified time (sleeping when you're supposed to be working is not the best thing to do) and our performance decreases.

The remedy for above problems is BlockingQueue.

The new producer is similar to previous one, except that it operates on BlockingQueue and doesn't use any synchronization on it, because it's thread safe.

There are some changes in consumer:
Apart from not using synchronization, we don't need to check if the queue is not empty, as method take() is doing it for us. We also don't have to sleep anymore, as it is also handled by this method: as soon as an element is available it will be taken from the queue.

Class to run it:
It hasn't changed much, we're using LinkedBlockingQueue as an implementation.
There are other implementations of BlockingQueue that may be helpful for our needs (e.g. that introduces priority to elements or some delay that is needed before taking).

Synchronization pitfall

Synchronized method modifier is equivalent to block synchronized(this). Not only invoking of such methods is expensive for virtual machine, but they're also a little bit risky. Object's monitor can be taken not only during method invocation, but also by another object that has a reference to it.
Let's take a look at this example:
Class Resource contains some object and provides synchronized methods for fetching it.
getVeryImportantObject() has synchronized modifier.
getVeryImportantObjectWithMutex() uses synchronized block on private object.

We also have an evil class:
Cheater owns a reference to Resource and it blocks it in blockResource() method.

The class that glues it together:
Pitfall invokes 3 threads. The first one uses Cheater to take the monitor of created object of Resource class. Next threads start after 1 second in order to allow the first one performing its task. The second thread tries to get resource object by using method with synchronized modifier, however it never succeeds. The third thread grabs this object by using method with internal synchronized block.
Project Lombok provides an interesting way of not getting into this trap (http://projectlombok.org/features/Synchronized.html)

Running threads using Executors

There are several ways of running threads.
We can create an instance of Runnable and pass it to Thread class:

Or we can override the run() method in the Thread class directly:
However the better solution (in most cases) is using the Executor interface.
It gives us a couple of benefits. In previous cases, if we want to start again the thread that has come to the terminated state we will get IllegalThreadStateException.
With Executor we can reuse the existing Runnable :
To prevent adding any more tasks to our executor we need to call shutdown() method.

What is even more important, it provides the ability to easily switch the implementation of running: using single thread, different kinds of thread pools or even scheduled periodic task.
We would just need to use different static factory method from Executors utility class:
This time our runnable is run using two threads from executor's thread pool.

java.util.concurrent.atomic package

Classes from java.util.concurrent.atomic package allow us to use single variables concurrently without blocking access to them. The typical usage example is increasing the counter that is modified by many threads.

Instead of using the synchronized block, that blocks the access to the counter:

or the synchronized method equivalent to the block with 'synchronized(this)':

you can use AtomicLong class, that guarantees non-blocking access:

Method incrementAndGet() besides incrementing counter's value, returns it.

Another typical usage is providing non-blocking access to an object, that is shared by many threads. Instead of synchronizing getter/setters methods:

you can use AtomicReference class: