We had a great Democamp and birthday party in Munich. Thanks go to all the speakers, volunteers and attendees!

The evening started with a keynote by Ed Merks. He summarized 10 very interesting years. Some of the events he mentioned were already known, some were surprising, e.g. when Ian Bull started to use EMF in 2003

The second speaker, Kai Toedter showed a real working demo of how to use Java web start to start an Eclipse RCP application. To make it even more interesting, he started his demo application using the internet connection from Sven`s phone. You can download his slides here.

Manuel Bork presented the new Mylyn-GMF integration that allows the use of task focus on diagrams. This feature is also integrated into UML Lab.

Frank Appel showed how to create dynamic Web-Applications with RAP and OSGi. It was quite impressive to see him turning parts of a web application on and off using an OSGi console. At the end, he also demonstrated the same application running on an iPhone using the native RAP client for iOS. You can find his slides here.

Maximilian Koegel and me did a short “KINECT with Eclipse” demonstration.  If you’re not familiar with this demo, you can see more here.

Then we had a short break with beer and of course a birthday cake. It must have been good -  I wasn’t even able to take a picture of the whole cake:-)

After the break, Andre presented the tool, Ceno. It can help to avoid conflicts in projects by showing who is working on which class in real-time. You can download his slides here.

Tom Schindl presented his project “e(fx)clipse” Eclipse Tooling and Runtime for JavaFX. The styling options and the DSL to declarativly create the UI were especially great. You can find his slides here.

Ekke presented his first experiences with Eclipse PlugIns for BBX Native SDK. This enables the development of applications for the next generation platform for Blackberry smartphones and tablets.

Maximilian presented what’s new in EMFStore. He showed an example of a tool based on EMFStore and also showed an integration of EMFStore with the e4 workbench model. With this integration, the e4 model can be versioned between developers using EMFStore. The changes can even be pushed to a deployed application. As an example, one can switch off a certain feature for maintenance. See here for more information.

Sven Efftinge gave an introduction to Xtend and why it can and should be used daily. Xtend is a very thin layer above Java offering some innovations such as closures, which are not available in Java. Later, Sven also showed how to develop a very simple DSL with Xtext in 10 minutes. You can find more information here.

Ed presented Xcore, a textual syntax for Ecore created with Xtext. Xcore allows the definition of EMF models with the same ease as writing Java code. It also makes it very easy to embed Operations written in Java.

Thomas Schütz presented “Developing Embedded Systems with eTrice.” To me, the most interesting feature was that events on the target can be logged to create Message Sequence Charts(MSC) of the running application. You can find his slides here.

Thanks to all the speakers, the attendees and the volunteers for making this a great event and see you at the next democamp!

Eclipse has two annual conferences, EclipseCon (North America) and EclipseCon Europe. These are great venues to learn about what’s happening in the Eclipse eco-system, explore up-and-coming technologies and get to know the wonderful people behind Eclipse.

If you’re wondering how a ‘simple IDE‘ can fill two annual conferences, please read on!

EclipseCon Europe had a number of tracks, including talks related to modelling, Java 7, and Machine-to-Machine compatibility (yes, Eclipse has technology in all those spaces).  EclipseCon Europe also hosted the Eclipse 10th Birthday party!

I attended the conference.  Unfortunately, there were too many interesting talks and I missed many of the ones I really wanted to see.  Luckily the talks are now on-line at http://www.fosslc.org/drupal/category/event/ece2011 (if you can’t find your talk, wait a few days… they seem to be uploading them as I type this).  By having the talks available, I was able to attend the conference, meet with all the interesting people and still find time to absorb the technical details. This is a great service, thanks!

I should also point out that the deadline for talk submissions to EclipseCon (North America) is Friday November 18th.

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

Consider this:

I measured the time needed to create 200 Buttons in RAP 1.4 and RAP 1.5M3, and it shows a considerable performance boost (at least for the browsers i tested). One reason for this is that we changed from quirksmode to standard rendering in IE9, which among other things, finally allowes us to use its new HTML5-features (in this case SVG and CSS3). I expect another little boost with IE10, which has even more CSS3 support.

However, what i did not expect was a significant improvement in any other browser, in this case Google Chrome. This is likely due to the implementation of the JSON-based RAP-protocol. It remains to be seen how this develops, as work on the protocol is still going on. Currently eval() is used to parse the JSON. In the final release we will probably use other methods, such as the native JSON-parser present in many modern browser. Older browser may gain only little or no performance.

What is really awesome though is the improvment of the GC/SWT-Canvas performance in IE9 (and only IE9). Drawing in browser (without any plug-ins) used to be a real pain. While other browser adopted the HTML5-Canvas and SVG standard very early on, Microsoft stubbornly stuck to its horribly old VML implementation, making my work needlessly hard. One of the main problems with VML is that it gets exponentially slower the more elements you draw, from about 200 elements on it’s almost painful to watch. But this is 2011, HTML5 is all the buzz, and even MS could no longer ignore it. IE9 now has a decent HTML5-Canvas implementation that we use in RAP 1.5, and it shows:

The fine print:
These results were achieved on my Windows 7/64bit Intel i5 2,4 GHZ laptop. No other systems or browser were tested. Measurement was done using JavaScript. The 32bit version of IE9 was used. I did only 3 iterations each, but the deviance was relatively small. The results in the final RAP 1.5 release my be very different due to ongoing development. You can check out the code i used here.

Tags: canvas, CSS3, html5, IE9, Internet Explorer, rap

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