Monthly Archives: November 2013

Writing unit tests using BDD style

Well written tests could be seen as part of good documentation, but rather often it is of no help at all. Take for example this test

public void testOne() {
String a = "Kalle";
int b = someService.someMethod(a);
assert(b, 2);

Seing this code or the test report does not give us a clue what the test does or what the code we are testing should do. There are better ways of doing this and I tend to favor unit tests using the Behavior-driven development (BDD) style to structure the unit test.
First of all it is important to give a (as close to) self explaining name of the test method of what the test is testing and the expected result. Don’t forget to remove the “test” in the methods name since it is obvious this is a test. The method is annotated, right? Secondly it is possible to use the given-when-then BDD styel in a unit test as well.

public void whenKalleIsUsedAsUserNameWhensomeMethodIsCalledThereShouldBeTwoOfThem() {
// Given a first name "Kalle"
String a = "Kalle";
// When service is requested for the number users with Kalle as first name
int b = someService.someMethod(a);
// Then there should be two of them
assert(b, 2);

This might a stupid example, but using this structure it makes it more obvious to the reader what the test is about. Using a proper method name makes it easier to spot what went wrong reading the error report of your build.

My first contribution to the Open Source community

Open Source

For the last decade I have used a lot of great and sometimes less great Open Source software in my attempts to build systems and software products. Most of them are published to be used under no obligations and others under restricted license terms. I am so grateful for all these work that others have done to make my life easier.


So, I decided it’s payback time to create my first Open Source project. I decided to use Github as repository for the software. Since my current main employer is Extenda I created a Organization account (

Software Package Data Exchange®

The first project is really about Open Source. At Extenda we use Open Source libraries from different sources and we think we do oblige to the different licenses regarding paying license fees, provides license texts, source code etc. However we really want to 100% sure and we have looked at different software and services and discuss with lawyers to find a way to improve our process and assurance. During that process I discovered the standard Software Package Data Exchange® (SPDX® - which goal is to provide a standard way to describe the different licenses a product/system is using with a RDF report.


Looking at their site there were no real community tools to generate such report. There were only commercial tools. Since Extenda uses maven site to generate product documentation including the list of libraries and the licenses we are using it felt natural to create a maven site plugin that could as part of the site genration phase create an spdx report file. The result is an spdx-maven-plugin ( and it is “published” and pushed to Github under Apache License 2.0. The current version is 0.0.1 and will still need a lot of work before it complies with the standard. I need to understand more how to write tests for maven plugins of this kind. Stay tuned…

Github Pages

I felt using the would not be enough and since Github provides Github Pages ( I created a “site” for organization Extenda ( and the plugin project ( Even though the documentation ( is rather straight forward I manage to misunderstand it partly because of my lack of practical experience with and Git and Github. But, finally I got it right so you should be able to do it as well :).


The maven plugin is of course built using maven and so far with a very basic test suite (“Hello World” more or less). The goal is to create a set of tests, but I need to learn how to create those maven plugin tests.
In order to verify from an external part I wanted to make sure the build was successful in a different environment than my own. Therefor I created an account at Cloudbee’s service BuildHive in order to build and run junit tests for the project (

GitHub and BuildHive works well together

BuildHive is free of use for public projects on GitHub and it is really easy setup a build project for a repository on GitHub. Once verified the connection between BuildHive and GitHub, using the GitHub credentials, you just select “Add Git Repository”

Add Git Repository

and you will se the list of your personal and your organization’s repositories on GitHub.

List of GitHub repositories

To add a build select Enable and the Jenkins project will automatically be created for you.

Enabled BuildHive project

If you select the link you will be redirected to the Jenkins project build. You will probably notice that the project is already built and and probably has failed. BuildHive tries to figure out how to build the project, but you will probably need to configure the project. Select Configuration and enter the Shell Script for your project. Since spdx-maven-plugin is built using maven I entered mvn package (other build management solutions are supported as well – magic).

Enter mvn package as Shell Script

Select save and now the projects can be built successfully.

Succesfull build

So far BuildHive has no support the artifact(s) to a repository of some kind. It is primaraily a build and verification service. An option is to create an account on CloudBees (DEV@Cloud) which is a paid service with a free entry level where you can build your open source projects. It allows to use private settings to build and deploy your project. BuildHive (and CloudBees) uses web hooks to be notified once a new push has been made to the repository on GitHub and a new build is started automatically.

It is fascinating how easy it is with these integrated services to setup a versioned controlled project, creating a project site and connect it to a build server.