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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

"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.

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:

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.

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.

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:

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.

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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 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.

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.

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 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.

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 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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.