In a recent blog post Peter Kriens commented that the OSGi service model is as important as object-orientation. I feel the same – I don’t want to write software without this concept anymore. But for me, the service model only makes sense when it’s used together with the modularity OSGi provides. I think the modularisation layer is the greatest advantage of the OSGi platform and the services are really only there to simplify the communication between modules.

When it comes to developing a REST API with Java, this advantage is missing in most of today’s libraries (e.g. Restlet or Jersey), because the Java language still lacks modularity. But especially for the design of a REST API this concept can be a great benefit, because it overcomes the limitation of only being able to separate REST services by url and Java packages. With modularity the service implementations can be separated into modules which improves the maintainability and the beauty of the whole system a lot.

A few months ago I discovered JAX-RS for developing REST services. (Before that I used Restlet.) I have to say that the JAX-RS API makes it really easy to develop REST services. See this article for a how-to. A reference implementation of this API is Jersey. The cool thing about this implementation is that it plays really well together with the OSGi HttpService and it ships as bundles. In this way we have the option to actively deploy REST services into the HttpService. But is this how we want to publish REST services? To me, it’s not!

In my ideal world I would write my @Path annotated Pojos and publish them as OSGi services. That’s it. The runtime should take care of publishing and service wiring. Sadly, Jersey has no built-in feature for that. This is the reason I wrote a little OSGi-JAX-RS connector. The only thing the connector does is that it publishes OSGi services as REST services using JAX-RS. Of course, there are OSGi remote services, but using them does not allow the use of JAX-RS the way I’d prefer, namely as a lightweight additional bundle.

You can find the connector in GitHub. To make it work simply install it into your OSGi instance by using this jar. (You’ll also find a p2 repository there). That’s it. The only thing you have to take care of is writing the REST services like the one in this example.

@Path( "/osgi-jax-rs" )
public class ExampleService {
 
  @GET
  public String seyHello() {
    return "JAX-RS and OSGi are a lovely couple.";
  }
}

The activator can then look like this:

public class Activator implements BundleActivator {
 
  private ServiceRegistration<?> registration;
 
  @Override
  public void start( BundleContext context ) throws Exception {
    ExampleService exampleService = new ExampleService();
    registration = context.registerService( ExampleService.class.getName(), exampleService, null );
  }
 
  @Override
  public void stop( BundleContext context ) throws Exception {
    registration.unregister();
  }
}

Further instructions can be found in the README of the git repository. It also contains two examples for using this connector with and without declarative services. In the second part of this blog series I will show you how to configure the services using the OSGi Configuration Admin Service and publish services on different ports within the same OSGi instance. I hope you enjoy this connector as much as I do.

Tags: jax-rs, jersey, OSGi, rest, restlet

As you might know from previous posts, most of my work time has something to do with the development of REST based systems. The systems we develop are mostly written in Java. To ensure that a system works, we have a step in our continuous integration process that executes integration tests before automated deployment is launched. With this short post I’d like to show you our setup for these integration tests because when I searched a few months ago the results were rare.

We write integration tests for REST systems with JUnit and restfuse. Check this post for a how-to on restfuse. Thanks to the Maven surefire plugin we can simply execute these tests in our maven build. Here is the build and dependency section of the test module’s pom.

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-surefire-plugin</artifactId>
      <version>2.9</version>
      <executions>
        <execution>
          <id>test</id>
          <phase>test</phase>
          <configuration>
            <testClassesDirectory>${project.build.outputDirectory}</testClassesDirectory>
          </configuration>
          <goals>
            <goal>test</goal>
          </goals>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
</build>
 
<dependencies>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.8.1</version>
    <scope>test</scope>
  </dependency>  
  <dependency>
    <groupId>com.restfuse</groupId>
    <artifactId>com.eclipsesource.restfuse</artifactId>
    <version>1.0.0</version>
  </dependency>
</dependencies>

Most of our Java-REST applications ship as war files.  So, at this stage the question becomes, “How can I test the war file I just built?” One answer is to hot deploy the war file and run the tests against it. But, for a hot deployment we need a server running tomcat (or another servlet container), right? Actually, we don’t . We can simply embed a Jetty plugin into our maven build, start it and deploy our war file using the Maven Jetty plugin. The related section in the pom looks like this:

<build>
  <plugins>
    ...
    <plugin>
      <groupId>org.mortbay.jetty</groupId>
      <artifactId>maven-jetty-plugin</artifactId>
      <version>${jetty-version}</version>
      <configuration>
        <scanIntervalSeconds>10</scanIntervalSeconds>
        <stopKey>foo</stopKey>
        <stopPort>9090</stopPort>
        <contextPath>/</contextPath>
        <tmpDirectory>/tmp/work/</tmpDirectory>
        <webApp>/tmp/test.war</webApp>
        <daemon>true</daemon>
        <reload>manual</reload>
      </configuration>
      <executions>
        <execution>
          <id>start-jetty</id>
          <phase>test-compile</phase>
          <goals>
            <goal>deploy-war</goal>
          </goals>
        </execution>
        <execution>
          <id>stop-jetty</id>
          <phase>verify</phase>
          <goals>
            <goal>stop</goal>
          </goals>
        </execution>
      </executions>
    </plugin>  
    ...    
  </plugins>
</build>

It is important that we deploy the war file before the actual test phase, in our example, during test-compile. To make this work we need to copy the new war file into the configured directory before we run the maven build. This can be accomplished with a simple shell script.  The following snippet shows how it looked for our jenkins job:

rm -rf /tmp/work
mkdir /tmp/work
cp $WORKSPACE/../job/**/*.war /tmp/test.war

A few last points.  In our setup we split the integration test build from the main build but you can merge them together as well. And, when using restfuse an important thing to keep in mind is that you need to configure the port to be the same as the one jetty uses to run the tests.

That’s it – short but efficient. Maybe you have a similar approach to share in a comment with us?

Tags: continuous integration, jetty, maven, rest, restfuse

With this effective Mockito Post I want to share a really simple pattern with you. We call this pattern “check answers” and we use it whenever we work with Mockito Answers. The code resulting from creating Mockito Answers generally looks ugly. But, as good programmers we care about test quality, right?

Let’s see how we can make better looking answers using the “check answer” pattern. Mockito’s Answers are great when you need to verify that a method was called with specific parameters, or you need to execute an operation that also needs to be mocked. I’m sure you have seen situations where Answers were very useful. Let’s dive into a simple example. Our fancy program consists of three classes which are listed in the snippet below.

public class MyRuntimeState {
 
  private boolean state;
 
  public void setState( boolean state ) {
    this.state = state;
  }
 
  public boolean isTrue() {
    return state;
  }
 
}
 
 
public class MyDelegate {
 
  public void doSomething( MyRuntimeState state ) {
    // do some fancy operation
  }
 
}
 
 
public class MyObject {
 
  private final MyDelegate delegate;
 
  public MyObject( MyDelegate delegate ) {
    this.delegate = delegate;
  }
 
  public void operate() {
    MyRuntimeState state = new MyRuntimeState();
    state.setState( true ); // this is the important fact we want to test
    delegate.doSomething( state );
  }
 
}

As you can see we have the Types MyObject, MyDelegate and MyRuntimeState. MyObject needs a MyDelegate in its constructor. In the operate method, MyObject calls MyDelegate‘s doSomething method with a newly created MyRuntimeState object. Let’s assume that for some reason our fake system needs a MyRuntimeState with the state ‘true‘ to work (be creative – it’s just an example ).  So, MyObject needs to set the state of the MyRuntimeState object to true. This is exactly the case where Answers are useful to verify that the state is true within the doSomething invocation (we can probably also do this with verify in this example, but there are harder operations out there where verify can’t be used).  Let’s look at the test for this mechanism.

@RunWith( MockitoJUnitRunner.class )
public class MyObjectTest {
 
  @Mock
  private MyDelegate delegate;
  private MyObject myObject;
 
  @Before
  public void setup() {
    myObject = new MyObject( delegate );
  }
 
  @Test
  public void testSendsRightState() {
    doAnswer( new Answer<Object>() {
 
      @Override
      public Object answer( InvocationOnMock invocation ) throws Throwable {
        MyRuntimeState state = ( MyRuntimeState )invocation.getArguments()[ 0 ];
        assertTrue( state.isTrue() );
 
        return null;
      }
    } ).when( delegate ).doSomething( any( MyRuntimeState.class ) );
 
 
    myObject.operate();
  }
 
}

You see that it’s a fully working test that tests exactly what we want, but it’s also a smell. I dislike several things in the testSendsRightState method. The first thing is the method chaining over several lines. The second thing is that we have an indentation level of three which leads to unreadable code. The third thing is that we can’t see at a glance what will be tested. The fourth thing I don’t like is that the assert statement comes before the actual operate call at least in the writing of the code. The last thing is that this method is way too long.

Let’s try to get rid of most of the smells by simply doing one refactoring. You may say that this is obvious, and yes it is;). We need to extract the creation of the Answer object into a separate method. I name these methods createCheck***Answer (*** stands for a named check) because the answers that will be created are invoking the actual asserts. The result can look like this:

@Test
public void testSendsRightState() {
  Answer<Object> checkStateAnswer = createCheckStateAnswer();
  doAnswer( checkStateAnswer ).when( delegate ).doSomething( any( MyRuntimeState.class ) );
 
  myObject.operate();
}
 
private Answer<Object> createCheckStateAnswer() {
  return new Answer<Object>() {
 
    @Override
    public Object answer( InvocationOnMock invocation ) throws Throwable {
      MyRuntimeState state = ( MyRuntimeState )invocation.getArguments()[ 0 ];
      assertTrue( state.isTrue() );
 
      return null;
    }
  };
}

This simple refactoring has a huge impact on our test method. The test method has only a length of three lines of code now. The indentation level is one. The call chain fits into one line. Even the createCheckStateAnswer is more readable because it’s not surrounded by chained calls. One drawback still resists this solution. That is, that the assert is now called within another method. To me, this is a very low price to pay compared to the problems in the first test. And, the best thing about this solution is that when you only read the test method you see at first glance that an answer called checkStateAnswer was created that obviously does something like check a state. Other programmers should be able to understand most of the test method without reading the createCheckStateAnswer method.

I know that this solution is very simple and for you, may be obvious. But when I started with Answers I didn’t do this for reasons only the Programming Gods know now. If you have any other things related to Answers in your repertoire please share them with us in a comment.

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4

Tags: junit, Mocking, Mockito, Software craftsmanship, testing

For several projects at EclipseSource we are creating REST APIs. I’m involved in most of them and there is one thing that bothers me with every project. That is, testing. I mean, of course we are writing our unit tests first and we mock our services to get fast unit tests, but at some point you also have to make sure that the whole system works with integration tests. And, when writing integration tests for REST APIs in Java, as far as I know, there are currently only two solutions.

The first one is to write plain JUnit tests and do all the requests yourself within the test methods (maybe with the help of utilities). The other option is to use a library called rest-assured. This library provides a kind of DSL for testing REST APIs. You can write your tests with JUnit and use mockito-like syntax to send a request and test the response. But this doesn’t feel like the right solution, because you always have to configure your request with real Java code within your test method. I would prefer a solution where I can simply configure the request using something like annotations and just execute the test after the request is sent.

Another thing that bugs me are asynchronous services. When it comes to handling asynchronous services you always have two options: callbacks or polling. How can I test those services? For polling it’s easier – you can loop the request code – but does this sound right to you? For callbacks you have to open a server, again within your test method or before. It seems there are no cool solutions for this right now – even rest-assured can’t handle these services very well. That’s why I took a little time and tried to solve these problems. The result is a small library called restfuse.

Restfuse is a JUnit extension. It introduces an annotation called @HttpTest which can be used to configure a request. The request is sent before the annotated method is executed as a test method. The response is then injected into the test object and can be used within the test method. It also provides some new asserts like assertNotFound or assertOk to test response codes. A simple @HttpTest looks like this:

@RunWith( HttpJUnitRunner.class )
public class RestfuseTest {
 
  @Rule
  public Destination destination = new Destination( "http://restfuse.com" ); 
 
  @Context
  private Response response; // will be injected after every request
 
  @HttpTest( method = Method.GET, path = "/" )
  public void checkRestfuseOnlineStatus() {
    assertOk( response );
  }  
}

And of course, it also solves the problem with asynchronous services by introducing two annotations called @Callback and @Poll which can be used together with the @HttpTest annotation. For more information on these tests for asynchronous services take a look at the restfuse site.

Restfuse is open source, licensed under the EPL v – 1.0 and is hosted at github. The 1.0 version is also in the Maven Central and online as a p2 repository (yes, it’s an OSGi bundle).  I hope this small library will help you as much as it helped me. I would appreciate feedback on how to make restfuse even better.

Tags: junit, OSGi, rest, restfuse, testing

This Effective Mockito Post will be IDE specific again but related to the last post on Mockito’s spies. If you’ve read Part 3 you should now be familiar how to use them to “pseudo mock” statics. When writing code it often comes to a point where we want to debug using single step debugging. When using Mockito and especially when spies come into the game there is still something pretty annoying.

That is, when we want to debug our Object-Under-Test’s real method and the object is a spy. When we try to step into the object’s method we always land in internal Mockito code. After a little reading we can drill deeper but the next landing place is in java.lang.reflect code and so on. To be honest, this is really not the nicest way to debug code. What I want is that regardless of whether I use spies or not, when I step into an object’s method I land directly in this method. In the past my workaround was to set a breakpoint in the test at the method call and in the method itself. This enabled me to stop at the first point and resume the execution until it stops the second time in the method. But there is a much more elegant way. Let’s see how we can do this.

First of all, let’s take a look at an example. The code below shows a simple test from the last Effective Mockito post. The test uses a spy to “pseudo mock” a static method. We set a breakpoint in the line of the isPropertySet call and debug this method. Sadly when doing this we run into the effect described above.

@RunWith( MockitoJUnitRunner.class )
public class MyObjectText {
 
  @Spy
  private MyObject objectUnderTest;
 
  @Test
  public void testIsPropertySet() {
    doReturn( "some runtime property" ).when( objectUnderTest ).getProperty();
 
    boolean isPropertySet = objectUnderTest.isPropertySet();
 
    assertFalse( isPropertySet );
  }
 
}

When using Eclipse there is a very simple way to avoid this called “Step Filtering”. We can add packages or classes to this Filterlist using the preferences. When filters are activated the classes will automatically be skipped during debugging. By setting a filter like the one in the screenshot below we can simply step over the Mockito and reflection code.

If you are not using Eclipse there is probably a similar way to achieve this with your IDE. It would be cool if you would share this tip with us in a comment. Meantime, I hope that Step Filtering is as helpful to you as it is for me.  Finally, I want to thank Fluffi and Frank for getting me to dive into this.

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: debugging, eclipse, Mocking, Mockito, test driven, testing, tips

In the previous Effective Mockito post we saw how to use the @Mock Annotation to get a clean test. In this post I want to show you how to use Mockito’s spy mechanism to eliminate testing troubles with third party libraries.

Testing is one of the most important things in software development. I assume you agree with me because you decided to read this blog post .  It goes without saying that when we develop software we often rely on third party functionality. This does not affect our testing because we can mock objects from third party libraries thanks to Mockito. But there is one thing that always ruins my karma…

That is, static methods. And even worse, static methods that depend on runtime state. I know there are solutions like PowerMock to enable mocking statics, but I think there is a more elegant solution to avoid the troubles with statics -  without manipulating the bytecode and without adding another mocking library, as we would with PowerMock.

Let’s dive into an example to see how. First, take a look at our third party code. In this example I know that I will have to use a static method from the framework which exists in the class FancyFrameworkUtil. The only purpose of this code is to show you that I have to use it and that the third party library changes its return type magically at runtime as the comment says (this sort of thing happens way too often).

public class FancyFrameworkUtil {
 
  public static String getProperty() {
    return "some runtime property"; // this property changes at runtime ;)
  }
 
}

Let’s get to the code we want to write: a highly sophisticated type called MyObject . This type has only one method called isPropertySet which will become API (by this I mean the method will be added to a public interface). The method only checks to see if the value of the third party’s framework has a specific value and returns a boolean depending on the value.

public class MyObject {
 
  public boolean isPropertySet() {
    String property = FancyFrameworkUtil.getProperty();
    boolean result = true;
    if( property.equals( "some runtime property" ) ) {
      result = false;
    }
    return result;
  }
 
}

We now know that the framework method returns a value that can change at runtime but this does not mean we can’t write a test.

public class MyObjectTest {
 
  private MyObject objectUnderTest;
 
  @Before
  public void setUp() {
    objectUnderTest = new MyObject();
  }
 
  @Test
  public void testIsPropertySet() {
    assertFalse( objectUnderTest.isPropertySet() );
  }
 
}

As you can see it’s a very straightforward test. But it’s not complete because we haven’t tested what happens when the framework’s property value changes. We can’t be sure if our MyObject#isPropertySet ever returns true. I’m sure you’ve had a similar problem in the past, too.

At this point we have a choice. Introduce another framework to mock the static framework method or do something like the following. First, we need to extract the call to the third party library in a separate method in our MyObject implementation. It’s important that we change the visibility of this method to package private. This is the price we have to pay. But I don’t think its a high price because this method will not become API and is only visible in the implementation’s package. By separating the interface and the implementation into different packages this really isn’t a problem.

public class MyObject {
 
  public boolean isPropertySet() {
    String property = getProperty();
    boolean result = true;
    if( property.equals( "some runtime property" ) ) {
      result = false;
    }
    return result;
  }
 
  String getProperty() {
    return FancyFrameworkUtil.getProperty();
  }
 
}

This is all we have to do to our implementation to enable the “pseudo mocking” of the FancyFrameworkUtil‘s method. Now comes the testing, and at this point we can use a spy. A spy is a real object with one or many mocked methods. Therefore we can spy on our objectUnderTest. In our case we want to mock the getProperty method that was added last. It can look like this.

public class MyObjectTest {
 
  private MyObject objectUnderTest;
 
  @Before
  public void setUp() {
    objectUnderTest = spy( new MyObject() );
  }
 
  @Test
  public void testIsPropertySet() {
    doReturn( "some runtime property" ).when( objectUnderTest ).getProperty();
 
    assertFalse( objectUnderTest.isPropertySet() );
  }
 
  @Test
  public void testIsPropertySetWhenPropertyChanged() {
    doReturn( "foo" ).when( objectUnderTest ).getProperty();
 
    assertTrue( objectUnderTest.isPropertySet() );
  }
 
}

As you can see in the test methods, the spying in the setUp method enables us to change the return value of the framework’s method by introducing a delegation step. With this we can ensure that our method isPropertySet reacts to changes in the framework’s property.

I hope it’s now clear how to use a spy to mock static framework methods by using delegation steps. If you know alternative ways, please take a minute to share it with us in a comment. By the way, there is also an @Spy Annotation you can use. Have fun spying

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: junit, Mocking, Mockito, Software craftsmanship, test driven, testing, tips

As promised in the first part of the “Effective Mockito” blog series, I will concentrate on Mockito specifics in the followup posts. So, the main topic for Part 2 is Mockito’s @Mock Annotation.

When I write tests I try to follow an explicit pattern, called the build-operate-check pattern. This was described by Uncle Bob in his book “Clean Code” (Page 127, Chapter 9). The main idea behind this pattern is that you try to split your test method into three parts. The first part sets up the environment, the second executes the method you want to test and the third part verifies the expected. You can also apply this pattern with Mockito using the @Mock Annotation.

When writing tests we often reach a point where we need a second object to get an object under test to work. That’s where we can use mocks . The test code looks roughly like this:

public class SecondPartTest {
 
  @Test
  public void testSomething() {
    Strategy strategy = mock( Strategy.class );
    Something objectUnderTest = new Something( strategy );
 
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
}

As you can see we created an object of the type Something. This object needs another object of the type Strategy in its constructor and I decided to use a mock for this. After this we execute the method we want to test which is called doSomething. The doSomething method should invoke the method doSomethingConcrete on the object we passed in the constructor. As you’ve probably noticed, it’s the strategy pattern. I chose this one because it’s a perfect fit for the use of mocks. In the last step of the test we verify that the method doSomethingConcrete was invoked. Nothing special here.

It looks like a nice and clean little test to me. But, in most cases we have more than one test method in a test class. When a new test method is added, it could look like this:

public class SecondPartTest {
 
  @Test
  public void testSomething() {
    Strategy strategy = mock( Strategy.class );
    Something objectUnderTest = new Something( strategy );
 
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    Strategy strategy = mock( Strategy.class );
    Something objectUnderTest = new Something( strategy );
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

At this point our nice and clean little test is no longer as nice or clean. By adding one test method we introduced two redundant lines of code, the object instantiation and the mocking. This is a sign that we need to use fields for both the objectUnderTest and the mock, and create them in the @Before method as in this snippet:

public class SecondPartTest {
 
  Strategy strategy;
 
  Something objectUnderTest;
 
  @Before
  public void setUp() {
    strategy = mock( Strategy.class );
    objectUnderTest = new Something( strategy );
  }
 
  @Test
  public void testSomething() {
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

This makes our test methods clean again, yippee . But I think we can do better. Mockito provides MockitoAnnotations and I’d like to use one of them in our test. It’s called @Mock (surprise).  Using this annotation we can tell a field that it is a mock.  It can look like this:

public class SecondPartTest {
 
  @Mock
  Strategy strategy;
 
  Something objectUnderTest;
 
  @Before
  public void setUp() {
    MockitoAnnotations.initMocks( this );
    objectUnderTest = new Something( strategy );
  }
 
  @Test
  public void testSomething() {
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

This has at least one major benefit. You can see that a field is a mock at first glance without reading the setUp method. However, we didn’t save any lines in the setUp method because we need to tell Mockito to instantiate the @Mock annotated fields. This looks really ugly because we are mixing Mockito framework code with our test code. We need to find another way to instantiate the mocks. Luckily, Mockito helps out once again.

Since JUnit4 you can choose specific test runners for test classes. You probably know this because you use it in your TestSuite classes all the time. Anyway, Mockito provides a runner called MockitoJUnitRunner. Using the runner looks like this:

@RunWith( MockitoJUnitRunner.class )
public class SecondPartTest {
 
  @Mock
  Strategy strategy;
 
  Something objectUnderTest;
 
  @Before
  public void setUp() {
    objectUnderTest = new Something( strategy );
  }
 
  @Test
  public void testSomething() {
    objectUnderTest.doSomething();
 
    verify( strategy ).doSomethingConcrete();
  }
 
  @Test
  public void testDelegateSomething() {
    when( strategy.doValidate() ).thenReturn( true );
 
    boolean isValid = objectUnderTest.validate();
 
    assertTrue( isValid );
  }
 
}

As you can see we could remove the initMocks call in the setUp method and we are nice and clean again. And, that’s how you can get to a clean test using the @Mock annotation. In the next Effective Mockito installment I’ll show you how spies can be used to get to a clean test when you depend on third party libraries .

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: clean code, Mocking, Mockito, Software craftsmanship, test driven, tips

Last week I talked to a fellow developer, Frank Appel, about Mockito. We’ve been using this mocking library for over a year. We both agreed that of all the innovations we’ve tried in the last year or so, Mockito has boosted our coding productivity the most. With this blog series we want to share our experiences with Mockito. You see that I used the word “effective” in the title, and, in this context I want to define “effective” as arriving at clean test and production code as fast as possible.

To understand these posts you need to have a basic understanding of what mocking is. I recommend reading Martin Fowlers article,”Mocks aren’t Stubs“. You’ll also need some practice with Mockito. But, since you found this blog, you probably searched for the term Mockito , so this should be a given. Anyway, there is a third thing, that only affects this first post. You need to use Eclipse as your IDE. This post shows you how to setup Mockito in your IDE for the daily work. If you are using another IDE and you know how to achieve what I have described here, please share your tips in a comment. The follow up posts will not require Eclipse because they will be more Mockito specific. Enough prerequisites, let’s start with with the first thing that will boost your Mockito experience.

I always write tests first. My goal is to come up with a first test method really quickly to be able to create all the classes that I need by resolving the compiler errors using Eclipse’s quick fix functionality (CTRL/CMD+1 is your friend). What would be ideal, is to create a test class and just write the test without importing all the other stuff.  The Mockito and Junit stuff should automatically appear in my content assist. When using Mockito, I want to create a test method, write “mo”, open the content assist and it should show me all the “mock” methods.

I’ll give you an example to make this clearer and to show how to achieve this. If I write a test method and open the content assist (which I use all the time), the standard selection options are very basic.

As you can see there are no “mock” methods but at least the Mockito classes. The reason is that the content assist only shows methods that are imported in the current class. So, by static importing Mockito this can be fixed.

But this is not what I want. This assumes that I have to import all Mockito stuff manually, or that I need to write “Mockito” and organize my imports automatically. I really want to be able to just write “mo” and get a pre-filled content assist. Luckily there is an option that lets us achieve this. In Eclpse it’s called “content assist favorites”. It can be configured within your preferences. Let’s take a look at our favorites.

As you can see, I added Mockito.*, Matchers.* and Assert.* to my favorites. This enables my content assist to show the available methods and import them when I’m using one. You may think, “hey, this will fill my content assist with unnecessary stuff when I’m writing production code.” But this is not the case. These imports are only available when Mockito and JUnit is on your build class path. So, by separating test and production code you only have these imports available in your test projects. Let’s take a look at the result.

As you can see I haven’t imported any Mockito stuff yet but I can select all the mock methods from my content assist. This enables me to write tests really quickly because I don’t have to think about setting up a test, I can just write it.

This is just a simple trick to come up to speed as quickly as possible when writing tests using Mockito. In the next posts I will focus more on the Mockito specifics. I hope you liked it and will stay tuned

Read the other Effective Mockito posts:

• Effective Mockito Part 1
• Effective Mockito Part 2
• Effective Mockito Part 3
• Effective Mockito Part 4
• Effective Mockito Part 5

Tags: Java, Mocking, Mockito, Open Source, TDD, tips

In my last blog post I introduced the idea of using OSGi services for single sourcing a RAP/RCP application. I think this approach is quite elegant, but it has one major drawback. When you use normal OSGi services in your application you will mix your application code with the OSGi Framework code everytime you reference or register a service. Not only does this look ugly, it’s also hard to test.

Luckily there is a lifesaver called Declarative Services. (For those of you who are familiar with declarative services, skip to the next paragraph.) The OSGi declarative services (ds) are specified in the OSGi compendium so they are standardized. It’s just a component framework on top of OSGi services. It gives you the ability to register and consume services in a declarative way using some xml files and simple accessors in your classes.

I’ll take the same example from in my last blog post and use it to look at ds for single sourcing.  In that blog, we single sourced a themed button widget.  We can use the same interfaces and service implementations, and the only differences will be how the services will be registered and referenced.

First, let’s take a look at the service registration. In our example we need to register the services in the rap and rcp bundles. It’s common practice to put all service declarations in a folder called OSGI-INF in the root of your project. Once you’ve created this folder you can create a “component definition” using the wizard. After this you need to fill in three things: first, the filename of your choice, second, the component name which needs to be unique in the framework and third, the component itself.

The component is the fully qualified classname of your implementation. In the case of service registration, it’s your service implementation. To add the service registration, press ‘Finish’ to open the component editor. We only want to register a service, so we jump to the service tab. In the bottom section you can add the service interface.

To understand what happens in the background let’s recap what we have declared. We defined a service interface, a service implementation, a component name and a filename. The component framework takes care of instantiating the service implementation and registering it as a service using the service interface. It registers the component using the component name. The filename will be automatically added to your bundle’s manifest. That’s all, the next time we start this bundle the service will be registered. Your component definition should look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" immediate="true" name="com.eclipsesource.app.rap.service.provider">
   <implementation class="com.eclipsesource.app.rap.RAPSingelSourcingService"/>
   <service>
      <provide interface="com.eclipsesource.app.ISingleSourcingService"/>
   </service>
</scr:component>

Now we get to the service referencing. As you recall, we need to reference the service in our app bundle. Therefore, we need to create a component in this bundle too. In this example I decided to reference the service in the bundle’s activator and provide it with a static accessor. But you can reference it wherever you want. In this case the component is our Activator. The only difference to the service registration is in the service tab of the component editor. Instead of providing a service, we are now referencing one. You can do this by clicking ‘Add’ in the upper section of this tab.

After this you need to declare the Interface of the service you want to reference, in our case the ISingleSoucingService. The question is now, “how does this service finds its way to the Activator?” The answer is binding methods. In the reference you can specify a bind and an unbind method e.g. setService and unsetService. You need to add these methods to your activator with the service as a parameter. That’s all – we are referencing the service now. Your component should look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<scr:component xmlns:scr="http://www.osgi.org/xmlns/scr/v1.1.0" enabled="true" name="com.eclipsesource.app.servic.consumer">
   <implementation class="com.eclipsesource.internal.app.Activator" />
   <reference bind="setSingleSourcingService" cardinality="1..1" interface="com.eclipsesource.app.ISingleSourcingService" name="ISingleSourcingService" policy="dynamic" unbind="unsetSingleSourcingService"/>
</scr:component>

The last thing we need is a little bit of glue to bring these components together. The glue is in the org.eclipse.equinox.ds bundle. This bundle contains the component framework implementation, and to make everything work together you need to add this bundle to your launch configuration. It’s not included in the RAP target components, but you can download it using the Indigo release site or the Equinox SDK.

I added a branch called “ds” to the repository on github from the last blog. This branch represents an example implementation using ds for single sourcing.

Have fun declaring services

Tags: declarative services, eclipse, OSGi, rap, rcp, rt, Single Sourcing

Probably one of RAP’s best known features is its single-sourcing capabilities. Some time ago we created a guide on Single-Sourcing RCP and RAP applications. The guide recommended a technique where a facade and fragments were used to invoke the RCP or RAP implementation during runtime. With this post I want to show you how to achieve the same the OSGi way.

For single-sourcing a RAP or RCP application, its straightforward to use the power of OSGi because it’s included in both platforms out-of-the-box. OSGi has a central concept called services which are simply POJOs and are used to allow communication between modules. And, you can register or resolve services at any time in your code.

The basic Idea behind using OSGi services for single-sourcing is as follows. We need to extract all the things that vary into separate, platform specific bundles. To use the different implementations, we have to create an interface in a “common” bundle that contains the methods we want to use. The platform specific bundles have to register an implementation of this interface as a service. In the “common” bundle we can reference the registered services and use them to get the platform specific stuff. More specifically, we register a RAP implementation in a “rap” bundle and an RCP implementation in an “rcp” bundle. The only thing we need to do then is to start the right bundles on the associated platform to get the right service.

With this solution we can extract the platform specific stuff into separate bundles and we don’t have to rely on fragments. So enough talking. Let’s look at some code. I decided to create a very simple single-sourcing interface which can be used to get the WidgetUtil.CUSTOM_VARIANT constant value. This constant exists only in RAP so, it’s a good example for showing how to handle the differences.

public interface ISingleSourcingService {
  String getCustomVariantString();
}

I have created three bundles: one that contains the application which is entitled “com.eclipsesource.app” and one for each platform. These are called “com.eclipsesource.app.rap” and “com.eclipsesource.app.rcp”. Both platform bundles implement the interface.
RAP:

  @Override
  public String getCustomVariantString() {
    return WidgetUtil.CUSTOM_VARIANT;
  }

RCP:

  @Override
  public String getCustomVariantString() {
    // There are no custom variants in RCP
    return "";
  }

And both bundles are registering the service in their Activator during the start method call.

  public void start( BundleContext bundleContext ) throws Exception {
    Activator.context = bundleContext;
    registration = context.registerService( ISingleSourcingService.class.getName(),
                                            new RAPSingelSourcingService(),
                                            null);
  }

When it comes to using the service in the common “app” bundle we can use a ServiceTracker to get the service implementation (you can also use DS).

  private ISingleSourcingService getSingleSourcingService() {
    // We use a tracker to get the service. We also can use DS to get it.
    Bundle bundle = FrameworkUtil.getBundle( getClass() );
    BundleContext context = bundle.getBundleContext();
    ServiceTracker tracker
      = new ServiceTracker( context,
                            ISingleSourcingService.class.getName(),
                            null );
    tracker.open();
    ISingleSourcingService service = tracker.getService();
    tracker.close();
    return service;
  }

The only thing we have to do now is to create two launch configurations which contain the associated platform-specific bundle.

That’s it! You can find the sources in this github repository. Have fun using OSGi services to single-source applications.

Tags: eclipse, GitHub, OSGi, rap, rcp, services, Single Sourcing