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.

Selenium WebDriver – the simplest possible start?

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

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

JBoss Drools – a hello world example

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

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

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

Test drive an implementation using an Executable Specification – revisited

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

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

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

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.

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?

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

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.