Normally, I like to make my unit tests so that they do not depend on external things running. As a general rule, I try to write tests that prove that the logic in my code works. While I care that communication between my application and, say, a database or application server works, it’s not my code that’s doing the communication, so I don’t tend to write unit tests that cover that. If I’m using something like Apache Jakarta Commons’ HttpClient to do some kind of communication via HTTP, I tend to write tests that confirm that the request (PostMethod or the like) is built properly by my code and that my code handles a return result correctly. With some layering it’s possible to structure you code so that these sorts of tests are easy to execute without actually doing the communication.

While I care that the HttpClient does what it’s supposed to, my unit tests tend to be more concerned with whether or not my code does it what it’s supposed to. Sometimes I will write some unit tests for frameworks that I use, but I tend to try and keep these tests isolated. But that’s a story for later.

The other day, I was inspired to write some unit tests that actually do the live communication between my Eclipse plug-in and an application server via HTTP. Setting this up is surprisingly easy using the Jetty and OSGi HTTP service bundles that’re already included with the workbench.

I added the following two methods to my JUnit 4 test class:

@BeforeClass
public static void startServer() throws Exception {
	Dictionary settings = new Hashtable();
	settings.put("other.info", SERVER_NAME);
	settings.put("http.port", 0);
	JettyConfigurator.startServer(SERVER_NAME, settings);

	ServiceReference[] reference = Activator.getDefault().getBundle().getBundleContext().getServiceReferences("org.osgi.service.http.HttpService", "(other.info=usagedata.upload.tests)");
	Object assignedPort = reference[0].getProperty("http.port");
	port = Integer.parseInt((String)assignedPort);

	tracker = new ServiceTracker(Activator.getDefault().getBundle().getBundleContext(), reference[0], null);
	tracker.open();
	HttpService server = (HttpService)tracker.getService();
	server.registerServlet(GOOD_SERVLET_NAME, new GoodServlet(), null, null);
	server.registerServlet(BAD_SERVLET_NAME, new BadServlet(), null, null);
}

@AfterClass
public static void stopServer() throws Exception {
	tracker.close();
	JettyConfigurator.stopServer(SERVER_NAME);
}

This code creates an HTTP server, asking the server to find an available port (which my client code needs to complete the communication) and then registers some servlets.

Some bundles have to be added to my test fragment (I tend to build unit tests for plug-ins in fragments):

• javax.servlet
• org.eclipse.equinox.http.jetty
• org.eclipse.osgi.services

In this example, I’m adding two servlets to the server, one that does good things and one that does bad things. The servlets are mockups of the real things that exhibit very specific behaviour for testing purposes. The code that I’m testing invokes these servlets via the aforementioned HttpClient framework.

I’m still not convinced that this is exactly what I want to do (I certainly have some Law of Demeter issues to work out with it), but it works well. The best part is that my unit tests can be easily automated since they don’t have to depend on some external thing being properly configured.

I’ve been having a hard time scaling this year. I’ve received far more requests for appearances than I’ve been able to satisfy. With this in mind, I’m undertaking an effort to update the Eclipse Evangelism site to be more useful (or, to put it another way… useful). I’ve started some work already, but I’ll start in earnest in the new year.

My plan is to first make the presentations I use at conferences, user groups, and other forums available. The plan includes providing an abstract for the presentation along with the materials in open document and PDF format. Some of these presentations are already available as Eclipse Resources. I’ve been spending some of my time recently adding presenter notes to some of the presentations I use the most. The presentations (and accompanying materials) will be made available under the EPL.

I’ve already started collecting names of folks who are interested in talking at some of these events. When I get a request to speak at an event that I can’t get to, I put the requester in contact with one or more of those interested speakers. I then leave it to the speakers to sort out arrangements for the event.

I’ve already got a pretty impressive list of speakers, but given how many people in the world care about Eclipse topics, I can always use more. If you’d like to be part of the excitement, let me know. And, as always, if you want some Eclipse content at your user group, conference, meeting, or whatever, let me know (wayne at eclipse dot org).

We’ve just published a new article on Eclipse Corner titled “Defining Generics with UML Templates” by James Bruck:

Generics in Java have been around for a while but support for mapping generically specified artifacts in UML to their Ecore representation is new to UML2 2.1. This article will walk the reader through the details of the mapping process with the end goal of producing generically specified code. This article assumes some level of familiarity with generics and is not intended as a tutorial in Java generics.

You can find the article here.

Every time I look at RAP, I break into giggling fits. This stuff is just plain cool (though it does make it hard to convince my wife that I am indeed working in my home office, but I digress…)

I’m planning to speak briefly about RAP during my “Eclipse and Java EE 5 development” talk (which, it turns out, I neglected to provide a description for) at JavaPolis this week. I used the creation review slides as a source of information for my own talk (with appropriate attribution, of course).

FWIW, I find that, in general, the creation review slides are a pretty good source of relatively high-level information about a project. The best part, is that they’re all in one place.

After much consideration (and some scrambling to get the slides together), the three-hour talk is going to something like this: I’m going to talk about using Web Tools to build Java EE artifacts like servlets, JSPs, and EJBs. I’ll likely do a demonstration covering servlets and JSPs. I’ll discuss JPA tools (Dali) and runtime (EclipseLink); depending on time, I’ll do a demo using Dali to integrate EclipseLInk into a Java EE infrastructure. Since Ajax is pretty hot, I’m planning to talk about and demonstrate the Ajax Toolkit Framework (ATF). Then I’m going to change gears and talk about Runtime Eclipse, including Equinox and Server-side Eclipse, Rich Ajax Platform (RAP), and Riena. I think it’s going to be fun.

If you’re going to be at JavaPolis this week, find me. We can podcast or something. It’ll be cool. Trust me.