I’ve found many people to care for a high unit test coverage. It tells you something about how well your code is tested. Or does it?

Unit tests typically test the smallest piece of code. It is an excellent strategy to write your tests in conjunction with the production code. The tests help you shape the interfaces and help explore the problem domain.

Big question is: does the business/product owner care? What do those tests tell him (or her) about the actual functionality delivered? Fairly little really, if any at all. This boils down to the next question: why care about unit test coverage then?

 Read more

In an ideal continuous integration pipeline different levels of testing are involved. Individual software modules are typically validated through unit tests, whereas aggregates of software modules are validated through integration tests. When a continuous integration build tool like Jenkins is used it is natural to define different build steps, each step returning feedback and generating test reports and trend charts for a specific level of testing.

FitNesse is a lightweight testing framework that is meant to implement integration testing in a highly collaborative way, which makes it very suitable to be used within agile software projects. With Jenkins and Maven it is quite easy to trigger the execution of FitNesse integration tests automatically. When properly configured and bootstrapped, Jenkins can treat the FitNesse test results in a very similar way as it treats regular JUnit test results. Read more

In this blog I will show a way to do performance testing with Selenium. The reason I use Selenium for performance testing is that some applications use proprietary protocols between the application layer in the browser and the server.

So just capturing the traffic between the server and replaying modified traffic is not that simple.

An example is testing GWT applications. In a previous blog I wrote why this is difficult.

To create a test script in Selenium the first thing I do is record a test with Selenium IDE
After recording a script I export the script to JUnit3 (Remote Control). This will generate a JUnit test script which can be run to test the application.

The next thing you need is a solution to run a lot of JUnit test cases at the same moment.

Here you see a visual representation of the whole test chain.

 Read more

Agile is a mindset.  It comes with certain behaviour and a certain culture.  As with many things most people and organisations have to go through some serious change before they can actually be successful within an Agile setting. Change is hard, and it takes time.  I strongly believe that it helps when you simply understand what you’re trying to achieve.

‘Agile’ is no buzzword or a complex management theory, it’s natural behaviour for millions of people;  It’s not for managers.  It’s for everyone and it’s easy to understand as long as you acknowledge that ‘being Agile’ has nothing to do with the process you follow or the tools you use.  ‘Being Agile’ is about culture, behaviour and mindset.

This post intends to reword the Agile Manifesto in a way that makes its meaning obvious.  Understanding something,  doesn’t mean you’re immediately capable of doing it, but it’s a very good first step and it will help you on your way.

 Read more

During the last 15 years modern communication means have taken a giant leap. The world is becoming smaller and smaller; working closely together with colleagues around the world on a daily basis is a reality for many people. This is particularly true in offshoring IT. The benefits are clear: more qualified people and lower costs, but there are also challenges.

In this blog I will show how offshore software development can be improved by using Agile principles and best practices. I will show you how the Agile Tester and Agile Testing practice play an important role in this approach. I assume that the reader is familiar with Agile Software Development and Scrum.

 Read more

A number of my colleagues and myself recently decided to share our knowledge regarding “performance” on this medium. You are now reading the first blog in a series in which I present a test-driven approach to ensuring proper performance when we deliver our project.

Test driven

First of all note that “test-driven” is (or should be common in the java coding world. It is, however, applied to the unit-test level only: one writes a unit test that shows a particular feature is not (properly) implemented yet. The test result is “red”. Then one writes the code that “fixes” the test, so now the test succeeds and shows “green”. Finally, one looks at the code and “refactors” the code to ensure aspects like maintainability and readability are met. This software development approach is known as “test driven development” and is sometimes also referred to as “red-green-refactor”. Read more

A number of my colleagues and myself recently decided to share our knowledge regarding “performance” on this medium. You are now reading the first blog in a series in which I present a test-driven approach to ensuring proper performance when we deliver our project.

Test driven

First of all note that “test-driven” is (or should be common in the java coding world. It is, however, applied to the unit-test level only: one writes a unit test that shows a particular feature is not (properly) implemented yet. The test result is “red”. Then one writes the code that “fixes” the test, so now the test succeeds and shows “green”. Finally, one looks at the code and “refactors” the code to ensure aspects like maintainability and readability are met. This software development approach is known as “test driven development” and is sometimes also referred to as “red-green-refactor”. Read more

In this post, my colleague Barend showed how one can conditionally ignore certain tests in JUnit. In this post we will take a look at how this can be solved in TestNG, another popular testing framework.  Read more

A useful technique that I reinvent every once in a while is conditionally ignoring JUnit tests. Unit tests are supposed to be isolated, but occasionally you hit something that makes assumptions about the environment, such as code that executes a platform-specific shell command or (more commonly) an integration test that assumes the presence of a database. To keep such a test from breaking unsuspecting builds, you can @Ignore it, but that means you have to edit the code to run the test in a supported environment.

Proper Maven projects put their integration tests in a separate source folder called src/it/java and put an extra execution of the maven-surefire-plugin into their pom.xml, tied to the integration-test phase of the Maven build lifecycle. This is Maven’s recommended way of setting these up. It ties in beautifully with the pre-integration-test and post-integration-test phases that can be used to set up and tear down the environmental dependencies of the integration test suite, such as initializing a database to a known state. There is nothing wrong with this approach, but it’s a bit heavy handed for the simplest of cases.

In these simple situations it’s easier to just keep the integration tests in the src/test/java directory and run them along with all your other tests. However, you still need a way to trigger them only when the right environment is present. This is easily dealt with by writing your own JUnit TestRunner and some custom annotations, as shown below.

 Read more

This year I have been working on several systems based on Akka, usually in combination with the excellent Spray framework to build fully asynchronous actor-driven REST servers. All in all this has been going very well but recently I had to reinvent a certain wheel for the third time (on the third project) so I thought it might be good to blog about it so others can benefit from it too.

The problem is very simple: Akka has great unit test support but unfortunately (for me) that support is based on ScalaTest. Now there is nothing wrong with ScalaTest but personally I prefer to write my tests using Specs2 and it turns out that mixing Akka TestKit with Specs2 is a little tricky. The Akka documentation does mention these problems and it gives a brief overview of ways to work around them, but I could not find any current example code online.
 Read more