Writing integration tests for RabbitMQ-based components

I’m writing this post after days of misery, reverse-engineering, github browsing and finding (sort of) clever ways to get yet one step closer to the goal mentioned in the title.

Before we dive into the topic, let me clarify a few things. RabbitMQ, an AMQP (advanced message queueing protocol)  compatible message oriented middleware, (in my understanding) has no in-memory message broker implementation. ActiveMQ, another AMQP compatible implementation, on the other hand does provide such a component – easy to configure and use. The problem is that ActiveMQ implements version 1.0 of the protocol, while RabbitMQ is on version 0.9.1, and the two versions, of course, are not compatible. That is the main reason one might need QPID, a third MOM implementation that comes with an in-memory message broker and is able to “speak” multiple versions of the protocol.

Continue reading “Writing integration tests for RabbitMQ-based components”

Book review: Sujoy Acharya – Mockito essentials

A few weeks back I was contacted by Packt Publishing to review a relatively newly published book: Mockito essentials. Without any further talk, let’s see:

I tried to read the book like I had never seen Mockito, or encountered any of the principles of mocking before. Under these conditions some of the chapters were very useful, others less. At many points I had the impression that examples int this book are (maybe) a bit too advanced for beginners, but not so useful for pros. This is mainly because people completely new to mocking/stubbing/faking may get lost in some rather complex pieces of code, while seasoned mockers are reading more advanced books. Continue reading “Book review: Sujoy Acharya – Mockito essentials”

JUnit’s ExpectedException @Rule

Some time ago I had written a post about different ways to deal with exceptions using JUnit. It’s time to augment that post with a truly great way to achieve the same result.

Let’s look at this through an example. The task will be to implement a little method for an insurance company that registers a car to be insured by its license plate number. In Hungary, license plates follow the LLL-DDD pattern, where L stands for an uppercase letter, while D is a digit from 0 to 9. The initial requirement is simple: validate whether the input string conforms to the pattern described above; if it does, save it, else, throw an IllegalArgument exception. Continue reading “JUnit’s ExpectedException @Rule”

String concatenation VS StringBuilder append

I often hear people claim that using string concatenations inside loops comes with a huge penalty given the performance. Usually no one knows exactly how much this penalty is; so I decided to measure it.

For this I created a very simple application, that keeps adding the string representation of the current iteration to the end of a String/StringBuilder, with the number of words increasing incrementally from 1 to a million. Actually, I am biased toward Strings, because I think they create cleaner and more readable code than StringBuilders. Having said that, let’s see how my tests performed. Here are the results:

String concat for 1 substrings: 0 millisecs.
StringBuilder concat for 1 substrings: 0 millisecs.

String concat for 10 substrings: 0 millisecs.
StringBuilder concat for 10 substrings: 0 millisecs.

String concat for 100 substrings: 1 millisecs.
StringBuilder concat for 100 substrings: 0 millisecs.

String concat for 1,000 substrings: 3 millisecs.
StringBuilder concat for 1,000 substrings: 0 millisecs.

String concat for 10,000 substrings: 179 millisecs.
StringBuilder concat for 10,000 substrings: 1 millisecs.

String concat for 100,000 substrings: 18635 millisecs.
StringBuilder concat for 100,000 substrings: 2 millisecs.

String concat for 1,000,000 substrings: 2919877 millisecs. //Well, this is more than 48 minutes… Sweet.
StringBuilder concat for 1,000,000 substrings: 24 millisecs.

In conclusion, in case of a loop with a thousand iterations makes no relevant difference with regard to runtime; above that threshold, however, it is not worth using Strings. I can hardly imagine such a huge String concat loop, though in production environments.

I have to say that the difference in the last case surprised me a lot; 48 minutes compared to 24 milliseconds, this is shocking (of course this is not a realistic example, I only included it for fun. Waiting for the app to terminate, however, was not funny at all).

That’s it, mystery solved.

Unit testing tips and tricks

There are some common patterns when it comes to unit testing. Not very hard to solve situations, however, it might take a little time to find a solution to them, especially for the first time.

In this post I’d like to share some ideas that always pop up when someone new to unit testing joins our team. These things may seem trivial after some practicing, but still. Someone might find it useful. The code examples will be in Java, the mocking -when applicable- will be done using JMock (the same principles apply to Mockito). Continue reading “Unit testing tips and tricks”

JUnit’s parameterized test cases

I like JUnit. I really do. It has really cool features that make my life easier when it comes to testing. I like how I can document my production code with a set of tests. I also like the clear way of separation of the test cases; that each of them have a unique, descriptive name; that they all represent a well understandable use case.

However, I hate, yes it’s true, I HATE this particular feature JUnit offers, namely parameterized test cases. Continue reading “JUnit’s parameterized test cases”

Cucumber fixture files

Just a really quick note today (after so much time),  namely fixture files with cucumber. Ever tried to -similarly to JMock- create a fixture file, with a @Befaore and/or @After annotation in it? That would be cool, because it would result in a clean design, reused code and of course you could avoid duplications. What I mean is something like:

import cucumber.annotation.After;
import cucumber.annotation.Before;

public class MyFixture

    public void setup() {
        //Awesome code here

    public void tearDown() {
        //Even more awesome code here

And then in the step definitions file:

    public class MyStepDefinitions extends MyFixture
         //Awesome tests here

If you haven’t tried it yet, then just don’t. If you have (like some guys I saw were asking about such things), then you know that this will result in an exception like this:

cucumber.runtime.CucumberException: You're not allowed to extend classes that define Step Definitions or hooks. class MyStepDefinitions extends class MyFixture</pre>
at cucumber.runtime.java.ClasspathMethodScanner.scan(ClasspathMethodScanner.java:64)
 at cucumber.runtime.java.ClasspathMethodScanner.scan(ClasspathMethodScanner.java:42)
 at cucumber.runtime.java.JavaBackend.loadGlue(JavaBackend.java:55)
 at cucumber.runtime.Runtime.<init>(Runtime.java:64)
 at cucumber.runtime.Runtime.<init>(Runtime.java:51)
 at cucumber.junit.Cucumber.<init>(Cucumber.java:58)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
 at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
 at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
 at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
 at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
 at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
 at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
 at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
 at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
 at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
 at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
 at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

So you can’t create a fixture file with Cuke hooks. However, if you’re using Cucumber in a Java project, than chances are quite high that you’re driving it with Spring. And if  so, you probably can do this:

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class MyFixture
    public void setup() {
        //Awesome code here

    public void tearDown() {
        //Even more awesome code here

As you can see those annotations are not Spring related, but don’t worry. Spring’s intelligent enough, so it can handle them. And baaaang, now we got a fixture file with a setup and a tearDown method that run before and after each test scenario. Fixture file ready, duplication eliminated.

Hope you’ll try it sometime.