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.

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.

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.

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

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.

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

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

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.

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.

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