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

Eclipse sure has made a splash over the years. In celebration of the 10th anniversary of Eclipse, I pulled all the Eclipse splash screens from Git and put them all here (I skipped a few when there were only minor updates to the copyrights, etc…).

Trick or Treat!

Just in time for Halloween the Eclipse and Equinox teams have a treat for all you IDE enthusiasts… Eclipse Juno Milestone 3.  The transition to Git initially slowed some of us down, but the development teams have picked up speed now. There are lots of new things in M3 to test out.

OSGi now has a new console. It uses the Apache Felix Gogo project and supports tab completion, command history, piping, grep, and a whole host of other things.

Other new features include a global debug toolbar:

And Java resource leak detection

Checkout the entire New and Noteworthy, or better yet, download Juno Milestone 3 and try it yourself.

Inspired by David Orme’s retrospective on Eclipse — and with the 10th anniversary of Eclipse almost upon us — I though I would share my personal history with the Tool, Platform and Community.

I first used Eclipse in January 2003.  I just finished my Master’s degree at the University of Waterloo and started a PhD at the University of Victoria.  I was at the IBM Toronto lab (I was there as a student full time from Jan 2003 – Aug 2003 before we moved out west).  My Master’s degree was in reverse engineering, C/C++ fact extraction and software architecture abstraction. My PhD took me completely out of my comfort zone as I started running user studies to see how people interacted with complex business process diagrams using WebSphere Studio (an IDE based on Eclipse).  The visualization tools were built with GEF — leading me into my first Eclipse project, the GEF project.

Dr. Storey, and some other researchers at the University of Victoria, were also looking at how Eclipse could be customized for teaching computer science.  This was known as the Gild Project.  I was loosely involved and helped out where I could.

At IBM I had the pleasure of working with Mike Beltzner. He ended up leaving IBM to take a role as the Director of Firefox at Mozilla. With the shuffling at IBM, I ended up working with a new product team, one which consisted of Ed Merks, Marcelo Paternostro, Dave Steinberg, Nick Boldt, and others. Yes, it was the EMF team.

This was before there was a Top level modeling project, before GMF or Xtext.  In fact, I remember some really interesting discussions with Ed about how EMF was going to support these fancy new generics that Java was introducing. I certainly didn’t realize at the time how lucky I was to be working with such a great group of people.  I consider Ed to be my first Eclipse mentor.

Part of our research led us to design a graph based visualization tool built for Eclipse.  I had this idea that we could mimic the simplicity of the SWT/JFace API for visualization widgets.  I met Erich Gamma at OOPSLA 2004 and he encouraged me to explore this.  My supervisor (the awesome Dr. Storey) managed to secure some funding and we hired some help and got to work.  This work eventually became Zest, and I first spoke about it at EclipseCon 2005 (my first EclipseCon).  At EclipseCon 2005, I met Mik Kersten, and he was interested in visualizing task contexts in Mylyn (Mylar at the time). We decided to make Zest an OpenSource project as part of Mylyn (Mylar).  I consider Mik to be my second Eclipse mentor. Eventually it became obvious that Zest was more general than a context visualization tool, and Zest was moved to the Graphical Editor Framework.

In 2006, a group of us from UVic got together to hack out a new Plug-in. We called the event “Raise a Plug-in”, and the result was “TagSEA: a tool for tagging and navigating source code“. In 2007, I attended EclipseCon again to talk about Zest (and TagSEA), and it was here that Chris Aniszczyk and Wassim Melhem convinced me to do a Summer of Code project building a PDE/Visualization tool using Zest.  I consider Chris and Wassim to be me third and forth Eclipse mentors.

By 2008, my PhD was finishing up and I was looking for work. When asked what do you want to do when you grow up? My answer was simple… I want to work on Eclipse.  So when Jeff McAffer contacted me about joining him at Code 9, I jumped at the opportunity. Jeff immediately put me to work on p2 where I had the great pleasure of working closely with Pascal Rapicault and the other talented committers on the p2 team. I consider Jeff and Pascal my fifth and sixth Eclipse mentors.

Since 2008, a few things have changed at Code 9.  For one, it’s now called EclipseSource. I still work on p2, but I also spend time leading our Yoxos product development. With over 300,000 Eclipse plug-ins in our archive, I get to see a different side of the ecosystem.  I also spend time thinking about Eclipse / OpenSource business models and work closely with my 7th Eclipse mentor, Jochen Krause.

I literally sit in my basement and hack Eclipse — a pretty awesome job.  I occasionally give lectures about software engineering and other computer science topics. When asked: why do you like working on Eclipse the answer is simple: The people. Where else could I work with Ed, Mik, Chris, Wassim, Jeff, Pascal and Jochen?  All companies have smart people, the Eclipse community has the smart people from all these companies.

Pascal Rapicault, DJ Houghton and I have been hacking on a new feature for p2. Since p2 has been migrated to Git, we created a new branch and started hacking away. We were not very concerned about each individual commit since this work was mostly experimental. We took some wrong turns, performed a few quick and dirty hacks, and generally left our branch in rough shape. However, during the process we learned a lot and finally got feature working, but we certainly didn’t want to merge this hack into master.

If 15 years of software engineering has taught me anything, it’s that you should not be afraid to hack, learn, throw away and then implement properly. Git makes this so much easier.  Here’s what we did.

To review, clean-up and commit this feature, we started by switching to our new branch and we squashed all the commits into a single commit. We did this because we didn’t care about the individual commits that made up this feature. (Note: Don’t do this on a production (shared) branch since this will re-write your history).

To squash commits, use interactive rebase.

Once we had a single commit that represented the feature, we rebased on top of master and merged the feature to the master branch. Now, we could stop here but this included all the hacks, false starts and ugly code that we don’t want in our final repository. We used a little trick that Chris Aniszczyk mentioned to me.  We reset the git index, but left the files in their updated state (read more about the Git index on Alex Blewitt Git Tip of the Week). This is done using a soft reset.  Make sure you don’t reset your index if you have already pushed your changes to a remote repository.

This essentially returns you to a state where all the files have out-going changes that represent the work we did. Now we could use git diff (or better yet, the s synchronized view in Eclipse) to review the commit, clean up the code, remove the unwanted changes, test our feature and finally, commit the feature properly (using a proper commit comment to indicate exactly what we did).

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

Munich Democamps have always been fun! Need proof? See here!

We are looking forward to celebrating Eclipse’s 10th birthday at the Democamp in Munich on November 15th. This time the Democamp will be located at the EclipseSource office (Agnes-Pockels-Bogen 1). The seats are limited to 100 so if you plan to attend, please register soon. If you want to present, please send me a description of the demo (jhelming@eclipsesource.com). Depending on the number of submissions, we might have to adapt the slots a bit. Please also register as a presenter.

In addition, I am happy to announce that we will have a keynote at the Democamp. To make it a little more exciting, I will not post the name yet. Instead, there will be a small challenge. This is how it works: I will answer one Yes/No question per day. You can follow this with the twitter tag #demoriddle. You can suggest new questions via twitter and I will pick and answer one every day. The first person with the right answer will get a Bavarian present at the Democamp. (Please do not participate if you happen to know already who it will be.) Each person is allowed only one guess, so take your time and choose wisely.

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

In Munich, we are currently looking forward to two events: The last week-end at the Oktober Fest and even more important the Eclipse Stammtisch on upcoming Tuesday 6pm. We have already over 20 registrations including the legendary Mr. Eclipse Foundation Europe, Ralph Müller.
Furthermore, we will have interesting demonstrations. Arno will present the Loggifier, a tool that inserts code into Java class files for logging, and the CVSTools. Maximilian and Edgar will present new features of the EMFStore including GIT Integration. Ekke will demonstrate the development of LocationBased Services with the BlackBerry Eclipse PlugIn. And finally I will try to get the KINECT running at Sappralot
However, if you are not in the mood to look at any demonstrations, just drop by for a chat and a drink.
If you have not registered for the Stammtisch yet, please do so: http://eclipsestammtisch.eventbrite.com/
I will update our reservation on Friday.
Looking forward to meet you there!