TDD with an AI assistant, my perspective as a beginning practitioner

I have been practising Test-Driven Development for more than 25 years. The red-green-refactor cycle is second nature.

I have of course heard a lot about AI tools and LLMs over the last couple of years. The times I have tried them, I have not been impressed. Their proposals didn't compile. They seemed to solve the wrong problem. This was probably because they lacked the context of the project I'm working on. Honestly, a lot of what I have seen has been rubbish.

Not too long ago I saw a thread on LinkedIn where some people who I know really know what they are doing discussed their experience with AI assistants and specifically Claude Code. I decided to give it a try.

Compare time with AssertJ

AssertJ is a great assertion framework for Java. It is in my opinion much better than any of the available alternatives. Two areas where AssertJ shines are verifying collections and verifying exceptions. It is also extendable, so you can implement custom assertions for your domain objects.

The way to assert something is done using the method assertThat(). A typical example looks like this:

assertThat(actual).isEqualTo(expected);

isEqualTo() is overloaded and can be used for a lot of comparisons.

Context switching in git

It happens that you are working on something and realize that you have to change context. Something urgent popped up and you need to get it into production as soon as possible. However, you have uncommitted changes that doesn't work properly. What do you do now? You can't commit your current changes. They are not done and should not end up in production. And you are smart so you avoid branching. Your current changes are on master and should be on master.

Delegating writing unit tests

Some time ago I attended a meeting where a developer told us that

The development is done. Wrote som unit tests yesterday. They are not done. I delegated writing them to a colleague.

A statement like that makes me very sad. It also upsets me.

Setting execution permission from git

The execution flag must be set on a file for it to be possible to be executed as a script on a Linux system.

Jenkins configuration as code

Configuring Jenkins is not as easy as one might imagine or want. There are some 1500 plugins available. Selecting the proper plugins and then configuring them is a daunting task.

Jenkins configuration as code doesn't solve the selection problem. But it does solve the problem of having a repeatable setup of Jenkins. The setup is version controlled and thus traceable.

Here is an example where I use this this tool chain:

• Jenkins
• Docker
• Java
• Maven
• Git

A working example is available at GitHub.

Two Jenkins jobs - one Jenkinsfile

I have a situation where I want two jobs in Jenkins to have the same definition. They will run a set of tests against two different environments.

I want to name the jobs so it is obvious which environment they target. My naming schema looks like this: *-dev

The jobs will therefore be named as:

• integration-tests-dev
• integration-tests-sys

Test-Driven development is hard

I had a conversation with a developer this spring about Test-Driven Development, TDD. We both agreed that it is a good habit.

I asked why he doesn't do more TDD than he does. He is not using TDD as his default mode when writing code. His answer fascinated me.

I don't know if it should be a rest api or something else.

If that is the conditions you work under, I can absolutely understand if TDD is the least of your problem. I can definitely understand if you don't use TDD in that context.

There are few problems here that will make it really hard to do TDD

What is the size of a baby step?

It is easy to agree that baby steps are good when doing something complicated. They allow you to move slowly but steadily. That is why baby steps are recommended when doing software development.

If we agree that baby steps are good, the next question is "How large is a baby step?"

This is where it gets interesting and this is where I see different interpretations.

What is BDD?

Defining what Behaviour-Driven Development, BDD, is not easy. It is sometimes described as a bounded context of ideas.

What is rather clear to me is that there are a two properties everyone seems to be able to agree upon.

These are:

• Conversations - talk to each other and get a better understanding
• Concrete examples - share concrete usage examples for a better understanding

In order to get full benefit from these, I want to add

• Automated acceptance tests - transform the concrete examples into executables examples
• Code - write the production code that implement the rules checked by the concrete examples

to the list.

How to implement a Cucumber-JVM plugin

Cucumber-JVM comes with some built in plugins. They are mostly used for reporting. If the built in plugins aren't enough for your needs, it is possible to implement your own plugin.

This blog post will show you how to

• Implement a plugin that will receive events from Cucumber
• Add that plugin as a part of your execution

Kubernetes service node port range

The default node port range for Kubernetes is 30000 - 32767. As it is a default, a reasonable assumption would be that it can be changed. So far so good. However, it turns out that the documentation on how to change the default is hard to find.

kube-apiserver

The port range is controlled by the kube-apiserver which is a pod running inside your Kubernetes cluster. It is created from a pod definition located in /etc/kubernetes/manifests/kube-apiserver.yaml.

A Jersey client supporting https

When testing a rest service behind https, you must be able to create a client that supports an encrypted connection.

The trick is to create a javax.ws.rs.client.Client and set the sslContext as well as the hostnameVerifier() properly.

Data tables in Cucumber 3

Version 3 of Cucumber for Java has recently been released. It brings Cucumber expressions to Cucumber-JVM. It also brings a new implementation of Data tables.

From a Gherkin perspective, nothing has changed. Data tables are supported as earlier. As a developer you need to adapt the steps a bit.

I T.A.K.E. Unconference 2018

In june 2018 I will return to I T.A.K.E. Unconference in Bucharest, Romania. I run two sessions there:

• Example mapping
• Selenium and the Four Rules of Simple Design

These two sessions combine something I think is very important. They combine clean and understandable code with discovering what to implement. Understanding what to do is often more valuable than to know how to implement something. Implementing the wrong solution may even be harmful and is just as much waste as implementing something wrong.

What does BDD really stand for?

BDD is the acronym for Behaviour-Driven Development. It is a way to describe the behaviour of a system and a way to make sure that it is developed to behave as it should.

BDD is used for understanding what to create and for verifying the result.

Business-Driven Development

But BDD could also be the acronym for Business-Driven Development. BDDers work really hard to bridge the communication gap between development and business. We really try to involve the business people in the development. We value their input and love discussing concrete examples describing what the system should do. How it is done is less important when understanding what really matters for the business. Focusing on the what and not the how is a differentiator between communicative developers and regular developers.

Testing stage 2018

In April I will be talking at Testing stage in Kiev, Ukraine

I have two sessions:

• Test automation - the supporting architecture
• Why is good design important for test automation?

They are connected in the sense that they are both about how to implement the support code you need for your test automation initiative. As a developer, I know that how you implement code is really important. It is ultimately a matter of maintainability. And maintainability is probably the most important property a piece of code can have after being correct. Code that can't be maintained will create problems for you during the entire lifetime of your product.

Getting started with Cucumber for JavaScript

I usually describe myself as a Java backend developer. That is actually not completely true. I tend not to shy away from the frontend, but I prefer the backend because it is usually much easier to test.

This backend focus has allowed me to almost entirely miss out on JavaScript development. I can't say that I mind that much. I use JavaScript when a web page needs it, but I use Google a lot to find examples I can modify to fit my needs.

One thing I am curious about though is to be able to use Cucumber-js. I have never done it before so this a blog post that will describe my experience getting started.

Languages supported by Cucumber-JVM

Cucumber-JVM supports a lot of languages for writing concrete examples that describes a wanted behaviour. The examples are written in feature files. The five important keywords are:

• Given
• When
• Then
• And
• But

These keywords are translated into many different languages. So many that it may be hard to keep track of them. How do you find the keywords for your native language? Luckily, cucumber can help with that using its built in help system.

Finding the Unknown Unknown

What is the unknown unknown?

The unknown unknown are the things, sometimes problems, of the task we are trying to achieve that no one has thought of. It is on the level that nobody is even aware about them, therefore the name unknown unknown. We don’t even know that we have a problem in this area. This is where the nasty bugs live and thrive in a software system.

Cucumber - tagging scenarios

When you do Behaviour-Driven Development, BDD, you start with a conversation. The conversation leads to concrete examples that can be used as acceptance tests. When you implement the acceptance tests, it may be the case that you can finish the development shortly after. Unfortunately, it may also be the case that the development will take some time. Maybe even a few days.

How do you handle the case where you commit your changes to your version control system and your continuous integration server build the system but the acceptance tests doesn't pass just yet?

There are a few different solutions you can use:

• Do not commit the new acceptance test
• Keep the current work in a separate branch that isn't built
• You comment out the example
• You tag your example in such a way that it will not be executed

Test automation and Selenium: 4 rules for keeping your tests simple

To support ever shorter release cycles you need to automate testing, and to do that, you need to use a program that can verify your desired behavior. One option is to use tools that can record and replay a scenario, but those are a nightmare to maintain, and you'll probably end up writing the code needed for automating the tests yourself.

For automating the testing of a web application, Selenium is a better way. It takes some programming skills, however, and you must take care to ensure that your tests are easy to understand and maintainable.

Writing maintainable, easy to understand tests might seem hard, but not if you follow these four, simple rules of design.

Sharing state between steps in Cucumber-JVM using Guice

A scenario in Gherkin is created by steps. Each step depends on previous steps. This means that we must be able to share state between steps.

The glue between Gherkin and the system under test is implemented as regular Java methods and implemented in regular Java classes. The steps are global in the sense that every step in the same package or subpackage relative to the runner will be found and executed. This allows us to define one step in one class and another step in another class.

Dividing steps between many classes may be a good idea. It is, however, probably not needed early in a project. The first reasonable division should therefore probably be no division. When you write your first scenario, you will most likely only have a few steps. Not more than that they can fit into one class without too much hassle. The first class with steps is probably small and you can easily find your way around in it.

The problem with too large step classes doesn't occur until after a while. You have added a bunch of scenarios to your project and finding your way around in the step definition class is getting harder and harder. The problem with large classes are that they

• are not coherent, they are about a lot of different things at the same time
• don't follow the single responsibility principle, there are probably many reasons why a class has to be changed
• are messy, it is hard to find what you need

You would like to split the steps into multiple classes. The question is how.

Gradle: setTestClassesDir(File) method has been deprecated

When upgrading from Gradle 3 to Gradle 4, I got a deprecation warning in my build. The message looked like this:

Gradle now uses separate output directories for each JVM language, but this build assumes a single directory for all classes from a source set. This behaviour has been deprecated and is scheduled to be removed in Gradle 5.0
        at build_6ku42cnecj8o3fcbd4eugmgr$_run_closure3.doCall(/Users/tsu/projects/tsu/thinkcode.se/build.gradle:37)
The setTestClassesDir(File) method has been deprecated and is scheduled to be removed in Gradle 5.0. Please use the setTestClassesDirs(FileCollection) method instead.
        at build_6ku42cnecj8o3fcbd4eugmgr$_run_closure3.doCall(/Users/tsu/projects/tsu/thinkcode.se/build.gradle:37)

My question was "What? How do I upgrade my build to get rid of the warning?". I searched but neither Google nor Gradle had a migration plan ready for me.

Use the same language

When implementing verification of an application using Cucumber, you have a choice of the language to use. Being able to choose is a good thing. But it also forces you to take a decision.

Cucumber is implemented in lots of different languages. The Cucumber site lists these implementations:

• Ruby/JRuby
• JRuby (using Cucumber-JVM)
• Java
• Groovy
• JavaScript
• JavaScript (using Cucumber-JVM and Rhino)
• Clojure
• Gosu
• Lua
• .NET (using SpecFlow)
• PHP (using Behat)
• Jython
• C++
• Tcl

That's a lot of options! What should you use? The consultant answer is: "It depends".

Sharing state between steps in Cucumber-JVM using Spring

A scenario in Gherkin is created by steps. Each step depends on previous steps. This means that we must be able to share state between steps.

The glue between Gherkin and the system under test are implemented as regular Java methods and implemented in regular Java classes. The steps are global in the sense that every step in the same package or subpackage relative to the runner will be found and executed. This allows us to define one step in one class and another step in another class.

Dividing steps between many classes may be a good idea. It is, however, probably not needed early in a project. The first reasonable division should therefore probably be no division. When you write your first scenario, you will most likely only have a few steps. Not more than that they can fit into one class without too much hassle. The first class with steps is probably small and you can easily find your way around in it.

The problem with too large step classes doesn't occur until after a while. You have added a bunch of scenarios to your project and finding your way around in the step definition class is getting harder and harder. The problem with large classes are that they

• are not coherent, they are about a lot of different things at the same time
• don't follow the single responsibility principle, there are probably many reasons why a class has to be changed
• are messy, it is hard to find what you need

You would like to split the steps into multiple classes. The question is how.

Gherkin scenarios - some good properties

Are there any global properties that a Gherkin scenario should fulfill? A short answer is, no.

A longer answer is that there are some properties that are good and probably useful in many different contexts.

Organising scenarios and steps in Cucumber

Writing a few scenarios in a feature file is easy. After while, when you have a lot of scenarios, you may want to divide them. How should you split them in such a way that finding a specific scenario is easy?

In the beginning it is easy to write the glue code needed to connect your scenarios with the system under test. But after a while it gets messy. You have a lot of methods and finding the one you need gets harder and harder. You need to start organising the steps in a good way to be able to find them without to much hassle.

These divisions can be done in a number of different ways. Some may support your development and maintenance. Other may hinder you. Is there an optimal division?

Sharing state between steps in Cucumber-JVM using PicoContainer

A scenario in Gherkin is created by steps. Each step depends on previous steps. This means that we must be able to share state between steps.

The glue between Gherkin and the system under test are implemented as regular Java methods and implemented in regular Java classes. The steps are global in the sense that every step in the same package or subpackage relative to the runner will be found and executed. This allows us to define one step in one class and another step in another class.

Dividing steps between many classes may be a good idea. It is, however, probably not needed early in a project. The first reasonable division should therefore probably be no division. When you write your first scenario, you will most likely only have a few steps. Not more than that they can fit into one class without too much hassle. The first class with steps is probably small and you can easily find your way around in it.

The problem with too large step classes doesn't occur until after a while. You have added a bunch of scenarios to your project and finding your way around in the step definition class is getting harder and harder. The problem with large classes are that they

• are not coherent, they are about a lot of different things at the same time
• don't follow the single responsibility principle, there are probably many reasons why a class has to be changed
• are messy, it is hard to find what you need

You would like to split the steps into multiple classes. The question is how.

Zero-downtime deployment with HAProxy as load balancer

I want to deploy new versions of an application with no downtime. It turns out to be a bit tricky. Here is one solution that sort of works.

How do you create a good specification?

A good specification is

• Easy to understand
• Executable
• Acting as an acceptance criteria

An interesting question is "How do you create a good specification?" There are obviously a lot of different ways to end up with a good specification. You may be lucky and randomly end up with something good. There are, however, better ways than to rely on luck.

What is the difference between a specification and a good specification?

What makes one specification a bad specification and another specification a good specification? What is the fundamental difference between two specifications?

Cucumber and Gherkin are not about flexibility

Sometimes I see questions asking for flexibility in Gherkin, the language used by Cucumber. The purpose is often to remove duplication. An example may be this Stackoverflow question

Removing duplication is often a very a good thing. It is, however, sometimes better to keep duplication and gain clarity and readability.

Creating confidence when testing

To gain confidence when testing software, you want to test the program as much as possible. The conventional way to do this is to test the application extensively through its external endpoints. These external endpoints may be a user interface or web services. They can almost always be be automated and automation is a good start.

Unfortunately, testing from the external endpoints leads to a few problems:

• The diagnosis when something fails is unclear - there are too many possible sources of errors
• The feedback to the developers is slow - the execution time is too long
• It is hard to have confidence in the tests - it's impossible to test all combinations of user input through the system

The cure is to rely as much as you can on fast unit tests. But a unit test will only test one thing. To know if a class can collaborate with other classes, you need to test that collaboration scenario. This can lead to integrated tests that have bad diagnosis precision, are slow, and have too many execution paths.

There is one alternative, though, that many developers hasn't explored enough. That is using unit tests with mocks and stubs in a strict way. I will explore this alternative in this post.

Why should you care about quality?

Brian McCallister tweeted "Current development speed is a function of past development quality."

It kind of summaries why I am passionate about code quality and taking the time early to do the right thing right.

Creating technical debt is like gaining weight

The traditional way to describe technical debt is to compare it to a bank loan. Something you do consciously. This is the way technical debt is described by Ward Cunningham[1] and Martin Fowler [2] .

Even if technical debt is usually described as a conscious decision, most technical debt seem to occur out of the blue. You realise after a while that you have it. If you are unlucky, you don’t even notice. The only indication you have is that seemingly simple things takes forever to implement. Your development becomes slower and slower.

Gatling - a tool for load testing

The documentation for Gatling tells us that "Gatling is an open-source load testing framework based on Scala, Akka and Netty". I have heard good things about it but never tried it.

The technical parts, Scala, Akka and Netty, were less interesting from my perspective. The interesting part was its developer-friendly DSL, Domain Specific Language. I have used tools like JMeter and I have never been impressed by their user interfaces. They are too complicated. As a developer, I like when I can specify my load script using my regular tooling. That is, an editor, a build tool and a command line.

The Right Tool for the Job

No tool is perfect for all jobs. When you start out automating Behvaiour-Driven Development, BDD, using Cucumber you tend to use it for much more than you need. This will work, but it is not a good idea for a few reasons:

• Cucumber is not a testing tool, it is a collaboration tool
• Unnecessarily complicated, testing tools like JUnit are easier to use

Cucumber Anti-Patterns

This a transcript and interpretation of a podcast where Aslak Hellesøy, Matt Wynne, and Steve Tooke from Cucumber Ltd have a chat about the BDD tool Cucumber and anti-patterns they have come across.

I have changed the order of the patterns described, rephrased some parts, and added a few of my own thoughts. The original podcast is available at https://cucumber.io/blog/2016/05/09/cucumber-antipatterns.
It is worth your time to listen to it.

Hamcrest, JUnit, Mockito, IntelliJ IDEA, Gradle, and java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch

Ever included Mockito in your project and lost the nice feedback from Hamcrest? And only when running your unit tests from IntelliJ IDEA? Instead of a message describing what you should fix, you see java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch

I have. More than once and been very frustrated. These are tools I like. Not getting good messages upsets me.

Cucumber regular expression cheat sheet

If you are like me, then you will feel a lump in your stomach when you realize that you need a regular expression. I think that the saying "If you have a problem that requires a regular expression, then you have two problems" is very appropriate most of the time.

It turns out that you need a some regular expressions when you are working with Cucumber. In this case, they are usually not very complicated.

Where should you use Behaviour Driven Development, BDD?

When I was at the European Testing Conference 2016 in Bucharest, a colleague asked me about my thoughts on how they should use Behaviour Driven Development, BDD. I didn't get a good chance to elaborate on my view so I decided that I should write this instead.

Dependencies between tests

A test must be independent. That is, a test should never depend on the result of another test.

If you run two tests in a specific order, you should expect the same result as if you run them in the reverse order.

Comments are deodorant for your code

Writing comments in a program is often considered a good habit. I hear people talking about code as "good and well commented". This always makes me skeptic. What do people mean with "well commented"? It turns out, they often mean that every method has a lot of comments.

Separation of concern when using Selenium

A lot of people want to automate testing of their web applications. This is definitely a good thing. But it happens that they focus more on the tooling than the testing.

Gradle and Cucumber-JVM

Gradle is a great build tool. Cucumber-JVM is a great tool for executing Gherkin. They don't really work well together. At least not out of the box. Gradle defaults to hide the output on stdout and stderr. This is very unfortunate since this means that the code snippets Cucumber-JVM suggests when there is a missing step are hidden.

Let me show you an example on how to setup a Gradle project so it can execute Cucumber-JVM and give you the snippets you want as starting points for your steps.

Continuous deployment - a case study

Continuous deployment is considered, among some enlightened, to be the holy grail in many organisations where software is developed.

What is continuous deployment then? My interpretation is that every change is deployed into production. That is, every change that passes the quality gates the team has created.

A relaxed version is continuous delivery. Continuous delivery means that every change that passes the quality gates ends up as a release candidate. A release candidate that is possible to deploy into to production. The deployment will, however, be done later. If ever.

I will describe how I implemented continuous deployment for one product and continuous delivery for three others for a client.

Expected exceptions

Sometimes you want to verify that an exception is thrown in your code.

Let me show you three different ways to verify that the expected exception has been thrown.

Different asserts are good in different situations

When should you use which assert? It is a question developers new to unit tests may ask themselves.

It is easy as a seasoned developer to think that this is obvious. It isn't when you are learning.

When is evolutionary design a good way to implement software?

Designing software can be done in different ways. The time and effort spent in designing have an important effect on the result. An interesting question is when should you you allow the software to evolve using Test Driven Development, TDD, and when should you not allow it to grow using TDD?

Software Development Gang

This blog post is the result of a session at an open space with the Software Development Gang in Ghent, Belgium, June 2015.

Conference do’s and don’ts

I have done some conference presentations the last few years. It is interesting to compare conferences in retrospective. It is possible to notice some common mistakes as well as some really good things. It is, unfortunately, often easier to criticize instead of attributing good things.

Most conferences I attend have very engaged organizers. They don't just do a job; they are passionate about it at the same time. It is great to be able to contribute in such environments!

Then there are some who just does a job and it is obvious that there is a difference.

RPM Cheat sheet

It turns out that I always have to search for the syntax when working with RPMs. To simplify my own life, and possible yours, here is a list of some commands I find useful. Some of them should be executed as root.

YUM Cheat sheet

Remembering the syntax for yum is something I seem to have problems with. To simplify my own life, and possible yours, here is a list of some commands I find useful. Some of them should be executed as root.

Increase the available disk on a CentOS host maintained by Vagrant and VirtualBox

Virtual servers are fantastic when you need to test something and want to make sure that you have a well know environment. A virtual server has no value. You can create it over and over again and it will only cost you some time to start and stop.

VirtualBox and Vagrant is a really easy combination to get started with. However, it may turn ut that the base box you use need to be enhanced. I will show you how you can increase the disk space available on the virtual host. Unfortunately, it isn't as easy as one could hope for. But it is possible and I will show you how. When the disk has been increased, I will repackage the virtual host so it can be reused easily.

Packaging a zip file from Java using Apache Commons compress

How do you create a zip file with Java? One option is to use Apache Commons Compress.

This example shows you how.

Tell, don’t ask

Objects that expose wrong information are complicated to work with. They force you to dig for the information you really need. It is easy to create a model where the users are expected to know a lot about the domain and therefore force them to dig deep into an object structure to get the information they currently need. This can be avoided if you strive for telling objects what to do and only ask them occasionally.

Include header and footer in a Mustache template

A template for creating web pages is great if you want to integrate front- and backend easy. I have been using Mustache for a while and I'm quite satisfied. It works great with both Dropwizard and Spark

The documentation says how to include a snippet from another template. But searching for it was not that easy.

Separating acceptance tests

It is very convenient to run the unit tests separated from other, slower, tests. There are different ways to do this. One way is to have a separate module for the acceptance tests.

Separating the modules is acceptable in some cases. It is not acceptable in others. There is a simple way to separate the source code for the acceptance tests while keeping the it in the same project if you use Gradle. Separate the tests with different source sets.

Separation on source sets means that you will keep all the acceptance tests in another directory structure than the unit tests. If you use the usual separation of production code and test code, then all you want to do is to add a new source set that contains the acceptance tests.

Stubbing a var arg method using Mockito

I had a need to stub a method the other day that had a var arg method. I failed in stubbing it using Mockito. It disturb me a lot. But after mulling on the problem a while, I searched and found a simple solution.

Mockito has a anyVararg() method that you should use when you try to stub a method that takes a var arg as argument.

A Gradle plugin written in Java

Gradle is a build automation system. You write your build script in Groovy. This is different compared to other build system such as Ant or Maven. They both use xml. Using Groovy instead of xml gives you a lot of benefits. You have an entire programming language at your disposal. This mean that you can easily customize the build behaviour.

If you, however, want to be able to do the same thing in many projects, it may be a good idea to write a plugin that you can refer to from other projects. I will show you, step by step, how to implement a Hello World Gradle plugin.

Gall's law

I saw a wonderful reference on Twitter the other day. It quoted something called Gall's law.

I looked it up and noticed that this seems to be a valid reference made by Dr. John Gall in a book from 1975.

When is it automated?

I had a discussion about an automation task that I have implemented the other day.

The task is about automating the deployment of a web application on top of a JBoss. The application is old and we are not allowed to do any improvements at the moment. The instruction is, deploy it as it is at the moment. You will be allowed to do improvements later when you are able to deploy the application smothly.

Which artifacts do you want when you build a system?

A Continuous Integration, CI, server builds a system every time a change has been detected in the version control system. This is a very common practice and something good. We are able to catch many silly mistakes early. The question is, what should the CI server build? Which artifact should the build produce?

BDD with Cucumber-JVM at GeeCON TDD 2015

This blog post is the same as the example I presented at GeeCON TDD in Poznan, Poland, January 2015. It is a step-by-step example that I hope you will be able to follow and implement yourself.

But before I begin with the implementation, let me reason about why you should care about BDD.

Behaviour Driven Development, BDD, is a way to try to bridge the gap between developers, who can read code, and people who are less fluent in reading code. Cucumber is not a tool only for acceptance testing. It is a communication tool where you can express examples in plain text that anyone can read. These examples can also be executed. They are the outcome from discussions between stakeholders, developers and testers.

Given this, the technical part of BDD that I will show you is the less important part. The most important part is the conversations that occurs and defines the application that should be implemented.

How do you recruit a good developer?

You are recruiting a new software developer to your team. How can you decide that this candidate is a good candidate?

The only good way I know is to work together. And do it for some time, preferably a few weeks.

Hard code first

I came across this tweet the other day:

"Novice engineers have not yet grokked this: the number of modes or options in your system is the *exponent* in how hard it is to maintain." by @zooko.

This is very true. The more options a system has, the harder it is to understand, maintain and use. This is one of the reasons why I usually always try to hard code things like parameters to scripts in my first iteration.

Hard coding is something that some of my colleagues sometimes have a hard time to accept. It happens that the argument is "I don't like hardcoded things". I can understand that point of view and I extract parameters when I have got one use case working with a hard coded solution. But I don't do it before I have something working.

Removing the auto generated class header in IntelliJ IDEA

My weapon of choice when it comes to editors is without question IntelliJ IDEA. It is great and behaves as I want and usually expects. It has, however, one feature that I find annoying and that I always remove.

IDEA will automatically insert a header with my user name and the date when I created a new class. I use version control so this information is never important. Adding a user name implies code ownership. Code ownership is against one principle I think is very important, collective code ownership. It is a core principle in XP with the goal to make sure that every developer feels that it is ok to work on all code in a project.

The header IDEA inserts used to include where to find it so you easily could find and modify it. Today, when I set up a new environment at a new customer, I noticed that the template had changed. It didn't tell me where to find the template. It looked like below:

/**
* Created by ${USER} on ${DATE}.
*/

An email marketing system built using test first and Cucumber-JVM

This is the example I implemented at JDD 2014 in Krakow, Poland at my Cucumber-JVM tutorial.

It is a (baby) step by step tutorial. The purpose for me taking baby steps is that you should be able to follow and implement the same things. Be prepared to spend some time with the implementation, it will probably take you a few hours.

Before we dive into the example, let me define what I am aiming for. My goal is to show you how an example (or specification if you want) can be executed. The example is written in plain text and is used to automate the testing of the system I will create. These executable examples can later be relied upon for regression testing and a living documentation.

Making life easier with a multi module Maven project

Working with slow modules in Maven is a problem. People will not build the module as often as they need and they will therefore not find problems as early as they could.

A solution could be to separate some of the slow stuff to a separate module. One separation can be to have a specific module for slow tests. This will, however, not solve the problem, that the module is too slow.

A solution to the problem could be to only include it in the execution when you invoke a specific Maven profile. This would separate the execution of a slow module from the execution of the rest, fast, modules.

Let me implement a simple example with two modules. There is the first module, the application, that we always want to build. It has fast unit tests and it is therefore not hindering to execute it often. Then there is the second module, the acceptance tests. It requires you to fire up your application before it can be executed. It is therefore dead slow. As a developer you will probably only want to execute the acceptance test module now and then.

Let me show you one way to achieve this.

Run SSH from Java

Suppose that you need to do something from a Java program on a remote Linux server? How can you do that?

One thing we know is that Linux servers usually supports ssh and that you can do everything you need from a command line. In other words, you need a Java implementation of ssh so you can execute whatever you need on the remote host. Next problem is to either implement ssh yourself or find an implementation that you can use. If you decide not to implement ssh yourself, you will probably prefer a self contained implementation so you don't have to include more dependencies than necessary. This is a good use case for Ganymed SSH-2 for Java. The only thing left is to:

1. Include a dependency in your Maven, Gradle or Ant/Ivy project
2. Implement whatever you want to do

I will show you one solution to 1 and 2 above.

Cucumber-JVM Hello world with Gradle

Cucumber is very easy to run from Maven. How do you run it from Gradle?

The answer to this question is: It is as easy as to run it from Maven. Depending on your background, perhaps even easier. The reason for this is because we run Cucumber from a JUnit runner. That is as a unit test with a specific runner. Maven or Gradle really doesn't have anything to do with this. It all boils down to the need for a Gradle project that can build a Java project. A Java project that has a unit test.

Comparing Maven and Gradle

I have been using Maven for a long time. I used to use Ant and it took me a while to get used to Maven and accept the Maven way. Reading a blog post from Neal Ford Why Everyone (Eventually) Hates (or Leaves) Maven got me thinking. He talks about the popularity of 4GL, Fourth Generation Languages, during the 1990s and why they never really took off. The idea was great, but they were not able to solve the entire problem good enough. They solved perhaps 80% easily and the rest was harder and the last part was even harder to solve. The customers want this last part as well and that is the reason why we use general purpose programming languages today.

I used Paradox to build a system for a customer a long time ago. I was able to solve most of their problems.

One thing though, there was an error situation and the customer demanded a correct error message. My problem was that it was a system error that came from the runtime environment that I couldn't control. My solution? To patch the binary that I delivered my application with. I replaced the error message with another message. I was lucky, the message I needed was one character shorter so the binary format was never changed. I am not sure that it was legal, I never asked Borland about it. But the error message became correct and the customer was happy and so was I.

Cucumber data tables

Cucumber has a nice feature that will help you to use tables in your scenarios. The table can easily be converted to a list or a map that you can use in your step. I will show you a few examples that may help you get started.

Cucumber-JVM Hello world

This is the example I showed at the I T.A.K.E. Unconference 2014 in Bucharest. I created it for your convenience so you should be able to implement it yourself after the presentation.

Before we dive into the example, let me just recap what I am aiming for. I will show you how an example (or specification if you want) can be executed. The example is written in plain text and it is used as the basis for an execution. This example can later be relied upon for regression testing as well as living documentation.

Use Maven build directory in your plugin

How can you get the build directory in your maven plugin?

The answer to this question may seem simple, just refer to ./target in your plugin and everything should work. This works in the simple case. It does, however, not work when you are using you plugin in a multi module project. Your plugin will not know where it is executed and cannot refer to a subdirectory relative to the directory where Maven is invoked. It may be executed in a multi module build or a single module.

Passing non primitive objects as parameters to a unit test

How can you pass a parameter to a unit test parametrised with JUnitParams? The answer is simple: As any other parameter.

Why Cucumber?

Before I can try to motivate why you should use a tool, let me define what it is and what it does.

What is cucumber?

Cucumber is a tool for collaboration and testing. It is used to create examples of behaviour that are executable. Creating examples in a collaborative way emphasize close cooperation between business analysts, testers and developers. The examples they come up with can be used as acceptance tests for the system being developed. It can be used as a testing tool where the tests are defined in a business friendly language while still being executable.

Goal

Our goal is to create a common understanding of the problem and therefore simplify the communication between all parties involved. We would also like to get something that is possible to use for automating the verification of the resulting program. That is, use as a base for test automation of the system.

Scripting with Ruby and Maven

In my assignment as a Configuration Manager, CM, I need to script a lot of things. I also need to automate the execution. Most of the stuff I build is built using Maven. Some is built using Ant. Both Maven and Ant are easy to run from TeamCity. But none of them are very flexible when it comes to scripting. Maven isn't designed for it and Ant is missing some features and get very verbose. The most important feature I am missing in Ant is repetition.

I saw a panel debate a while ago where three guys were discussing their favorite tools. The tools represented were Scala, Ruby and Groovy. One thing that I remembered from that session was that the Scala guy mentioned that he often used Ruby when scripting. My problem with using Ruby is that I don't have control over my execution environment. I can't install tools in it. I am not interested, either, because that wouldn't scale very well since the installation done on our build servers are done manually. I can, however, expect that Maven and Ant will work.

Given that I can expect Maven to work, I decided to try to execute a Ruby script from Maven. It turned out to work very well. I was able to reduce the size of an Ant script with 50% on my first attempt. In my opinion, the readability increased a lot. I was able to write the script more or less as prose.

If you are interested, this is how I did.

Test automation

A lot of people and companies are talking about and thinking of test automation. It seems to be like a holy grail within software development for a lot of people.

I am, however, sometimes wondering if they have thought this through properly. A few questions are important to know the answer to before you start a project that aims to place a product, or a project if you want, under automated testing. It seems to me as if a lot of people haven’t thought enough of the question why or the question what. Focus is often on the question how and almost never on where or when. How is obviously important, but if why and what hasn’t been properly understood then the how is uninteresting. Where is also important to decide upon. Some things should be tested through the final user interface, some things should be tested on the inside of a system. Some things should be tested with unit tests and some things at other levels. Finally, it is important to decide when the tests should be implemented. Tests can be implemented first, last or during the implementation of the system. This may not seem to a big deal, but it turns out that it is.

But let us start with the why.

Parametrised unit tests

Writing unit tests that test almost the same thing may introduce duplication. A solution could be to create parameters that should be varied in a list and iterate over it. Yet another solution is to create a parametrised test. Let us look at an example where these three options are explored.

Resources

It is common to talk about resources. Unfortunately what we mean is often people who we want to help us with something. A project need resources to be able to solve the task.

System Under Specification, SUS

Ian Kelly called the System Under Test, SUT, the System Under Specification, SUS, at his session “Testing++ – Working with Spock and Geb” on Java Developer Day in Krakow.

How is a hero created?

A hero in an organisation is someone who is considered to be indispensible. The organisation will not survive without this person. The hero is the only person with a specific knowledge. A hero sacrifices himself for the organisation.

Is the parameter used?

I watched a presentation by Zsolt Fabok a while ago and saw a technique I hadn't thought of before. How do you verify that a parameter is used in a simple way? Feed the method with something that usually doesn't work and verify that something happens.

Hero culture and curling

What is the problem with one hero that always solves any problem? One answer is that those who get problems solved never learn how to deal with the problem and solve them. What is the problem with this? One answer is that you build an organization where the bus count is one. One person always solves any issues and the organization doesn’t know how to do it. When this person steps out in front of a bus and doesn’t show up at work, then there is a real problem.

Change the binary path for a Windows service

Do you need to change the path to a binary a Windows sevice is executing? Maybe you want to change the location of where a service is installed?

Teaching - the difference between a lecture and a conversation

There is a big difference when teaching a large group and teaching a small group. I recently had the pleasure of teaching the same material in a few different scenarios. One of them with a large audience of about 70 participants. It took me approximately 2.5 hours to go through all slides and coding an example. Two other scenarios was with small groups with less than 10 participants. The exact same material took a little over a little over 3 hours to complete.

Embrace change or embrace uncertainty

Kent Beck wrote a very nice book eXtreme programming explained with the subtitle "Embrace change". But what he really want to embrace is uncertainty. What is uncertainty? It is those things that will happen but you are uncertain of. Possibly so uncertain that you haven't even thought about them in a risk analysis. It is the very nature of uncertain things, you don't think they ever will occur and can therefore not even think they might happen. They will therefore never turn up in a risk analysis.

Maven - the simplest possible introduction?

Maven is a build tool for Java. You define a project with Maven, build and test your product.

Usually you hate Maven or you love it. Before you have understood how things work, you usually hate it. If you persist, then there is a chance that you will like it.

I have met many developers that claim that Maven is either "To complicated" or "Impossible to understand".

I have even been asked "Don't you feel dirty using Maven?" during a session at an Agile conference. My answer was "No, why should I feel dirty for using a good tool?" This question and an opinion stated at another conference triggered me to write this. I aim to show you how Maven can solve some problems, using baby steps and starting from the simplest possible solution that could work. My goal is to write an easy to understand getting started guide. If you think I take a too large step somewhere on the way, please give feedback and tell me where I take a large step. If you think my steps are to small, then you probably already know enough about Maven so you don't need this introduction.

Take control of your time

Testing is all about verifying that something works as expected. What are the challenges then? There are many, one very obvious is to actually know how it should work. Another challenge is to isolate the system under test so that it is possible to know what is tested and determine if that specific part works as expected.

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.

Cucumber-JVM - not just for testing GUIs

Cucumber is a tool that supports Behaviour Driven Development, BDD. A lot of people think that the only place where a system has behaviour is in the user interface and especially in the graphical user interface. As a developer I know that this is not the case. All systems have behaviour at different places and different levels.

I will show an example of how a system can be developed using its desired behaviour and start from a non graphical point. I will work from the model down to the database and when I'm happy with the logical behaviour I will add a graphical user interface on top of it. I will actually add a few different interfaces; two web-based, one swing and two different types of web services. The result will be an example of Model View Controller, MVC, developed using BDD.

An important point when I add the GUIs or web services is that I will not change the desired behaviour. I will only change how the behaviour is verified. This is one way of showing you that Cucumber and BDD is not about testing GUIs. It is about systems behaviour.

Building the model

Previous - Introduction

The feature I will start with looks like this:

src/test/resources/se/waymark/rentit/Rent.feature

Feature: Rental cars should be possible to rent to gain revenue to the rental company.

  As an owner of a car rental company
  I want to make cars available for renting
  So I can make money

  Scenario: Find and rent a car
    Given there are 18 cars available for rental
    When I rent one
    Then there will only be 17 cars available for rental

It consists of three parts:

• Given - the preconditions of the system under test. The setup of the systems state if you want. In this case make 18 compact cars available for rental in the system.
• When - the actual change of the system. Transforming it from the initial state to the final state. Rent one car.
• Then - the expected final state of the system. The verification that the state change was the desired change. After one car is rented, there should only be 17 left to rent.

A JSF web application

Previous - Building the model

Many modern applications are built as web applications. The benefits are obvious, you don't need to package your software in shrink-wrap and send it to your customers. Upgrading is easy, you have to upgrade the server you host the system on and that's it.

The first user interface I will add to the rental system will therefore be a web GUI. It will be the simplest possible solution and the goal is not to build a fancy web app. The goal is to show how Cucumber can control a tool like Selenium WebDriver to assert the behaviour of the web application.

A Wicket web application

Previous - A JSF web application

A wicket application is yet another web application. I divide the project in two parts as earlier. The only large difference is the support class that will connect to the system under test. It has been adapted for another web application.

Building a Swing GUI

Previous - A Wicket web application

A Java Swing application is yet another graphical user interface that can be attached on top of the model developed earlier. The project is divided in the same way as earlier, in two parts. The only large difference here is the support class. It need to be adapted for a Swing user interface. Another difference is of obviously that the GUI is developed using Swing. But that has actually a rather small impact on the verification.

A RESTFul Web Service

Previous - A Swing application

A RESTFul web service is yet another way to use the model. It doesn't have any user interface and it is expected to be used by third party suppliers. I divide the project using two Maven modules as earlier. One for the production code and one for the verification. The only large difference here is the support class that will connect to the system under test but now has to be adapted for a RESTFul web service instead of any graphical interface. Another difference is of course that there is no GUI and that it is developed using a Jersey servlet instead, but that has little impact on the verification.

A SOAP Web Service

Previous - A RESTFul web service

A SOAP Web Service is yet another way to use the model. It doesn't have any user interface and is expected to be used by third party suppliers. I divide the project using two Maven modules as earlier. One for the production code and one for the verification. The only large difference here is the support class that will connect to the system under test but now has to be adapted for a SOAP web service instead of any graphical interface or RESTFul web service. Another difference is of course that there is no GUI and that it is developed using a CXF instead, but that has little impact on the verification.

Conclusion

Previous - A SOAP web service

I have shown you five different ways to implement something on top of a common model using the same behaviour. I hope you can agree that it is obvious that BDD and Cucumber-JVM is not just meant for testing GUIs. It can be used to assert any behaviour.

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.

All computer systems are equal

All computer systems are equal, but some systems are more equal than others. At least on a high level.

They are all subject to these actions:

• Enter data
• Apply business rules - morph the data
• Persist
• Retrieve the transformed data

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.

Want change and is willing to change

If you want changes and are willing to change, where should you start? When should you stop?

This is a very large subject. Books are being written on it. And it will always depend on the situation. But lets assume a few things.

• We are talking about software development
• We want our product to be awesome and profitable

Want change but don’t want to change

I have met several customers and potential customers that want to implement automated testing. They have been in very different areas; insurance, transport, telecom and so on.

One thing they have in common though, is that they want a change but they are reluctant to change.

Separating tests in Maven

The way Maven file structure is defined is a great way to separate unit tests and production code. Unit tests are fast. So fast that developers developing using Test Driven Development, TDD, doesn't have any performance problems when applying the Red-Green-Refactor cycle in their work. A large unit test suit is expected to be executed in seconds.

There is, however, no standard on how the files should be structured for slower tests (integration/acceptance/system et.al.). A common property for these tests is that they are slow. They often require a complete system setup in a known state. They use the filesystem, network, database and similar slow resources. Slow tests are normally not executed often. Developers seldom have the patience to wait for a build a long time before writing the next thing. Using them in a Red-Green-Refactor cycle is not practical. It takes too long time.

So what options do we have to separate the fast units tests and the slow tests? There are two main tracks that I have explored.

• Separating tests with name or package conventions
• Separating slow tests in a test module

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.

Pair Programing

How do you solve a problem best? In your solitude alone or in a group? I know that I solve problems better in a group. The group has to be small so you don't get disturbed. But it has to be large enough so a discussion can occur.

Programing is not about writing text fast. Typing is never the bottleneck when programming. The bottleneck is problem solving and solving the right problem.

Pair programming is about two persons that solve a problem together. Problem solving in a group tend to result in better solutions. Different people see a problem from different angles. The result is usually better than a solution that one person came up with.

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.

Challenging requirements

I attended a session with Gojko Adzic at Valtech in Stockholm in feb 2012. Gojko had some great comments about requirements and especially challenging requirements. A challenging requirement is a requirement from a customer that there is some kind of issue with and therefore something that will bring you problem.

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?

Missing ant-jsch.jar

The distribution of Ant 1.8.2 is broken on Mac.

ssh from Ant

You have to patch Ant in order to run ssh from it. It needs a ssh implementation that isn't bundled with the default distribution. If you just define a task like this:

<sshexec host="somehost"
    username="dude"
    password="yo"
    command="touch somefile"/>

Then you will get the error message below back.

How many train wrecks are lurking in your code?

Train accidents are mostly considered to be bad things. People tend to get hurt when trains have accidents. Never the less, it is not so uncommon with train wrecks in software development.

Train wreck code is code that calls a method on the return value of another method call. This chain can be very long if a value is excavated deep down in a object graph.

Testing a Web Service with SoapUI, JUnit, Maven and Cucumber

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

I will show how SoapUI can be used to test a web service. I will also show three different tools that can be used to control SoapUI. This tool chain can easily be made a part of your continuous build.

The simplest possible solution

The simplest possible solution that could work. Ever heard that expression? What does it mean? Really?

The answer is obviously something that in a really simple way satisfies the test you currently are working on. Nothing more, nothing less.

Why separate test definitions from a driving JUnit class?

Why should the step definitions be separated from the driving JUnit class when using Cucumber for Java?

Testing a web application with Selenium 2

Selenium a great tool for testing web applications. The current version, Selenium 2, is a merge between Selenium and WebDriver. I will walk you through an example where we test a web site using Selenium in a few different ways. This is the same example as I demonstrated at Scandev on tour in Stockholm 18 October 2011.

Maven Java heap space

I just had test in a Maven build fail with

java.lang.OutOfMemoryError: Java heap space

Why isn’t my tests being executed?

Have you ever wondered why your Maven project doesn't find and execute your tests?

Test drive an implementation using an Executable Specification

An example is perhaps the best way to describe something. Concrete examples are easier to understand then 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.

Test drive the implementation of a database layer

Development guided by test is perhaps the best way to make sure that your solution works and is possible to verify. I will show how you can develop a database layer guided by tests. It will be divided into two parts. The first part will be an in memory solution and the second part will be implemented using Java Persistence API, JPA, and Hypersonic. The second implementation is supposed to replace the first one guided by the tests developed for the in memory solution.

What is the difference between i++ and ++i?

During a coaching session I got a question about a loop.

Would there be any difference in the output from a loop defined as

for (int i = 0; i < 3; i++) {
    System.out.print(i + " ");
}

and a loop defined as

for (int i = 0; i < 3; ++i) {
    System.out.print(i + " ");
}

in Java?

Magic numbers

The other day a colleague asked me, what is a magic number? He had noticed that one of the things our Sonar was complaining about was Magic numbers. I got a great teaching moment and told him my view of Magic numbers.

Magic numbers are any numbers in the source code that just appears without any explanation.

Do not return null

Using your IDE to automatically create methods for you maybe a disaster waiting to happen.

Install a 3:rd part lib in Maven

Suppose that you have a dependency that looks something like this:

<dependency>
    <groupId>foo</groupId>
    <artifactId>bar</artifactId>
    <version>1.0</version>
</dependency>

that can't be resolved and the build fails with the error message below:

A Generics example

Generics has been a a part of Java since Java 5. It will allow you to write code that handles types without deciding which type upfront. This is of course very useful for collections. It used to be done using the inheritance system and casting Object to the type you knew should be used.

FEST Assert - a fluent interface for assertions

Hamcrest is a great framework for assertThat and it is bundled with JUnit. It is getting some competition from another framework, the FEST assertThat framework. The idea behind FEST is to use a fluent interface. This means that you can use your development environments code completion features to build your asserts. Its main goal is to improve test code readability and make maintenance of tests easier.

Software craftsmanship and raising the bar

What is software craftsmanship about? It is about different things. One of them is technical excellence.

Why should you use different technical practises when you develop software?

Why not hack away as usual and hope for the best?

Four rules of simple design

There are the four simple rules for software design that you always should follow. They are, in order of importance:

What is you passion?

A colleague of mine said a while ago that he used to ask that question to a certified scrum trainer. The trainer always answers that he will have to get back with an answer. One can speculate in why the person who got the question didn't have a good answer ready. The are a few options, either he does what he does because he has a passion for it or because he is good at it and it pays good money.

Set working directory for your Jenkins continuous build server

How do you set the working directory for your Jenkins (formerly known as Hudson) continuous build server to something else than System.getProperty("user.home")+"/.hudson"?

Create an executable jar from Maven

Creating an executable jar from Maven is not really hard.

This example will show you how you can include stuff in a jar and make it executable while not including stuff that is needed only during the build.

Build is platform dependent

Chasing the warning:

[WARNING] Using platform encoding (MacRoman actually) to copy filtered resources, i.e. build is platform dependent!

Unmappable character for encoding UTF-8

We had a problem in my current Java project. Whenever somebody wrote a comment using Swedish national characters, åäö or ÅÄÖ, and later tried to build the system with Maven we got the error:

unmappable character for encoding UTF-8

Stating the obvious

Today I got a call. Somebody couldn't get scp work from Ant.

Maven and Antrun

A friend of mine needed an example of how to use the Antrun Maven plugin.

This is a simple example that will show how to execute any Ant targets from a Maven build during the install phase.

Failing Maven builds in Hudson

Maven has a default behaviour that it fails a build if a test fails. Hudson and Jenkins turns this default behaviour up side down. Maven builds that fails are marked as unstable instead of failed. This behaviour may be surprising to anybody setting up a Maven build.

Automatically integration test an ejb with Maven

We want to perform an integration test of a system using Maven. The application must be deployed on an application server and the application server must be started before we can perform the integration tests. The application should be undeployed and the application server should be terminated after the integration test has been performed no matter what the result of the test was.

How can this be achieved with Maven?

Parameterized JUnits tests

We want to run the same test more than once and only vary the parameters. The solution is to use JUnit and run our tests with the Parameterized JUnit runner.

Maven and JBoss ESB - Hello World

I want to build a Hello World example for JBoss ESB using Maven instead of Ant. The original example bundled with JBoss ESB is using Ant. I have created a pom.xml that will do all the magic and re-located the example files to fit into a Maven structure.

Dependency injection

Dependency injection is invaluable when building software. Decoupling components means that it is possible to test them independently.

How to convert a POJO to XML with JAXB

We want to convert a POJO, Plain Old Java Object, to xml and we don’t want to alter the POJO in any significant way. How can this be done?

HttpComponents - a great tool with great examples based on a future release

Open source is a great thing when it works. It happens that the documentation is less then perfect or that the examples provided doesn't work out of the box.

Getting started with Continuous Integration

A quick Continuous Integration introduction example.

Integration test a web application with Selenium

We want to build a web application and we want to test it automatically.

Hibernate, Spring and Maven

We will create a small Java application that connects to a database using Hibernate. We will use Spring to wire stuff together and Maven to build it.

How can I create a simple web application using Spring MVC?

I want to to create a very simple web application using Spring. I want to create it using Maven as build tool.