Test coverage – friend or foe?

Measuring the test coverage is something many people think is a good idea. But is it a good idea? It depends on the quality of the tests. Test coverage may be a good measurement if the tests are good. But suppose that we have a high degree of test coverage and bad tests?

I will show two examples of how to get a 100% test coverage using Cobertura. They will be based on a set of good tests and a set of bad tests.

How is test coverage calculated?

Test coverage is calculated by recording which lines of code that has been executed. If the code has been executed through a test in a testing framework then we have calculated the test coverage.

The calculation is done using these steps:

• Start with instrumenting compiled code
• Execute the instrumented code
• Each execution of a line is recorded in a log
• Combining this execution log with the source code enables us to calculate how many lines out of the total number of lines that has been executed

We will be able to say that 47% of the lines in the source code has been executed. If the execution is done through test code, this will give us a measurement of the test coverage.

Selenium WebDriver – the simplest possible start?

Getting started with Selenium WebDriver may be an issue. You must write some code and get the code running. I have created what I think is the smallest possible solution that could work. It consists of two files, a project definition and the actual test.

You will need to have Java and Maven installed. I will not tell you how this should be done, it depends on your environment and operating system.

JBoss Drools – a hello world example

What is JBoss Drools? It is a framework where you can create rules that defines when a specific action should be done. This could be done in code using conditions. Creating them using a rule engine can make it easier to combine many business rules with many actions.

I tried to get a JBoss Drools example up and running. It turned out that the examples I found on the web were either were very complicated, tried to solve all possible problems or was just incomplete. I ended up writing my own example where I have removed everything that I didn’t find necessary.

I divided this example in two parts. First part is the simplest possible solution that could work, a Hello World. In the second part I try to do something that actually could be useful. I trigger a rule and instantiates a class that could perform some action.

Test drive an implementation using an Executable Specification – revisited

An example is perhaps the best way to describe something. Concrete examples are easier to understand than abstract descriptions.

I will show how Cucumber-JVM can be used to specify an example and how the example can be connected to the system under test, SUT. The example can then be executed using any IDE or using Maven.

Performing an action when a test fails

JUnit supports annotations so a method can be executed first in a test class or before each test method is executed. It also has annotations that supports methods to be executed after each test method or after the test class. This is very good if you need a common setup and a common tear down.

The after methods don’t give you access to the test result. You cannot know if a test method failed or not. This may pose a problem if you have a need to perform some specific actions after a failed test. A solution could be to implement an onError() method. But JUnit doesn’t support it.

A solution is to employ a @Rule annotation.

Adding a JUnit test template in IntelliJ IDEA

A test template for JUnit tests doesn’t exist out of the box for IntelliJ IDEA. Creating one is not complicated.

The goal is to create a simple template that will assist you when you need to write a test in JUnit. I want it to look something like this:

Using Hibernate Second level cache in JBoss 5.1

Enabling second level cache in a JBoss when you use JPA 1 is actually relative easy. Understanding how to set its properties is also not to difficult to do. Finding how to specify which configuration file to use when setting the additional configurations is more difficult.

Execute tests in random order

It works on my machine!

Ever heard that from a developer? I have, and it happens that the reason is that it actually works on their machine. It may also be the case that the order in which tests are executed matters. Test classes depends on each other and the order they are executed in is important. The solution is to execute the tests in random order so that any dependencies between tests are found and can be removed.

What is a good test?

A colleague asked that question the other day. What is a good test? It is a really difficult question to answer. There are a number of properties that hold true for a good test. I will list some of them and discuss why I think they are important. Others may think that the order of importance is different or that other properties are more important then those that I list.

I will show some examples using Java and JUnit of what I think are bad tests and how they can be refactored to something better.

Tests are automated in my world. I always try to avoid manually testing. The main reason for this is that manual testing is slow and hard to repeat arbitrary many times. Therefore, test should be read as automated test in for the rest of this text.

Test coverage in a multi module Maven project

Test driving a project should result in a test coverage of 100% of the code. But how can we know what test coverage we have? Is it even important?